I recently attended a demo of a large-scale enterprise system, whose web pages may be customised to the point of including fields added by the client. The way I understand it, their architecture is made up of the following layers:
Database
Web service API
XML files that dictate layout
The web pages that are generated from the XML files.
When I was asked to investigate building a web portal which could be easily branded, that struck me as a good way of going about it. The question now, is how one would design it.
I understand the database and web service layers, but I am a little confused by the various possibilities for building web sites in .NET.
Considering the requirement for customisability and the architecture from above, here is how I understand the options:
Webforms - the option I am most familiar with, but it is essentially enriched HTML with code-behind. I think there will probably be a lot of work to make it work with the idea of an XML layout.
WPF - the XAML middle layer is built-in, but as I understand it, WPF can only really be used in browser applications and not websites.
Silverlight - more for building applets than websites, right?
MVC - This looks interesting, but all the demos I have seen use Entity Framework as well. It seems to me like Entity Framework with all its automatic code generation is much more suitable to applications that are all new. In my case, I have a very large database that already exists.
If none of the above are suitable, I thought of an alternative. One could do a stock standard Webforms site with a web service that returns the branding elements. That isn't quite the same as what I described at the top, but is sufficient for my needs.
Or am I barking up the wrong tree?
I think you're off on your criticism of MVC. First, you don't need to use Entity Framework, and secondly even if you did, you can do it database first to generate your entities.
Your assessments of WPF and Silverlight is pretty spot on imo.
You could do this with webforms, but I think you'll probably find doing it with MVC architecture will be cleaner. Very simply, if you use clean HTML and put all branding elements into an external CSS file (logos, colors etc), then you are half way there to a custom brand. Even a different layout could potentially be defined by the CSS file (although it might be harder for your end users to customize that look since they would need to know css pretty well)
Building additional fields is potentially more difficult:
Off the cuff, the way I'd be looking at implementing this would be a combination of my predefined fields in a standard database layout (users table with username, password, first name, etc etc) and additional support for the "customizable fields" using the Entity-attribute-value pattern
From there you will need to develop an extensible system to 1. generate a page from xml with the appropriate form elements (select, text input, textarea, etc). 2. Generate a generic model that will read the same XML file and be able to receive data from a posted form and know how to save that to the database (note in this case if it was ALL entity-attribute-value that would probably be easier to manage than a combination of standard relational and EAV).
You'll probably want to look at .NET Data Contracts as serializable entities to get an understanding of how you might design your XML files to be extensible to allow for things like "select menu has the following 3 options" or text input must match this regex.
Really keep an eye towards extensibility, because you can't build it all at once.
Related
We are looking to build multiple custom websites for different customer contracts, with tailored functionality, but all around the same theme and concept.
There will be about 70% commonality in functionality across all websites, but enough difference that building a CMS is a bad choice. Also customers dont want their DB to have properties that are not relevant to them.
The DB tables will be mostly the same, with a few different properties in each table per site. ie a customer table might be 80% the same, but in one project in might also ask for hair-color, eye-color, etc. whereas in another in might also ask for height and weight....
I'm ok with my other layers, but what is the best practise for the MVC presentation layer?
I want to create as many inherited functions/controllers/actions/resx/etc as possible via base classes (which will be the same project referenced by each website), but MVC does not seem to lend itself as well to this as webforms.
Any thoughts would be really appreciated, thanks
I would focus my efforts on the web config and building my presentation layer around config settings stored at server side. Also, I'm not entirely sure how logically different your pages will be, but having different CSS styles can dramatically change the look of your websites. This post was kinda vague, I hope I helped spurn some ideas...
I was using WebForms earlier, now I'm very satisfied with the MVC. But as for the many tutorials I have read the words from those articles that to combine MVC and WebForms may be useful sometimes, but they didn't reveal the essence in their tutorials/articles more specifically.
For e.g.:
http://www.codeproject.com/Articles/575397/An-Absolute-Beginners-Tutorial-on-ASP-NET-MVC-for
quote
In fact the possibility of being able to mix both the styles is the best thing. We can use both these styles in a single application and get the best of both worlds.
And the same words for the others tutorials, which I read. I can't see any concrete.
As for me, what strong sides I've noticed, when I've used WebForms:
development style, which is more like to the desktop-development style, when I've first used WebForms, I feel like I was developing some WinForms/WPF application
page life cycle gives not only big headaches but also a very good mechanism for controlling webpages events/render html code. Yes it's complex and hard to learn/understand, but when you have done it you may to develop a very powerful application. I have done such perversions, where I was imitating a desktop developing style (I have built smth similar to the html collector, which may free some html code and include/render another and it was looked like a manager which manipulating scenes for future rendering like in WPF/Silverlight development and I was able to manipulate 30 different html pages only in one page (which I think many developers prefer to divide into such amount of pages) with such a self-developed manager).
Why do I tell you these things? I see that you may think that I switched to another topic and changed the meaning of my question and make it meaningless.
No! It's not, I've just provide such an information, because I don't understand where are those needed/correct parts of combining those two techniques for the real practice.
These two techniques have different life cycles, they works on different patterns, they render their pages very differently, they are just very different.
I can't imagine how it could be combined.
Maybe I don't know something...
Please tell me your opinion about combining them.
There is fresh MSDN Magazine article related to your question.
It may be necessary to fallback on traditional webforms if you rely on complex user controls specifically created with the webforms model in mind (needs viewstate etc).
MVC follows the HTTP protocol more closely while WebForms tries to abstract it away by creating an experience much more similar to that of WinForms.
We have a ten-year-old ASP application that we are considering planning an update for. We want to take advantage of the new technologies that ASP.NET has to offer, as well as the opportunity to fix some issues with the existing framework (the existing code-base is highly fragmented, nearly impossible to test, let alone debug, and the entire application appears to have been constructed according to the "Farmhouse Pattern".)
To that end, it seems that the time has come to rebuild this application. But, we are a small business, and we simply don't have the resources to either hire out the rebuild, nor to dedicate our small team of developers solely to the task of rebuilding (we've got other tasks on our plate, and can't concentrate on this one particular task for the length of time it would take to fully reconstruct the application).
What, then, are some useful strategies we can employ to help us convert this app, without having it consume all of our limited resources for the duration of the re-write?
Sounds like an interesting challenge. It's definitely not going to be easy, especially if you can't dedicate any resources to the project full time.
If you have a 10 year old application that is working, I would suggest not going for a complete re-write at all. I would start by sitting down and figuring out what you want your end product to be.
Is it going to be an ASP.NET MVC Web Application, an ASP.NET WebForms App, or something else? Once that decision is made, come up with a loose design for an architecture. If you do things correctly, you can build out bits and pieces of the business logic in .NET and utilize it from your Classic ASP code until you're ready to re-write the UI in .NET as well.
I agree with what Justin said; if you have a working application in place, you'll need a compelling reason (i.e., money) to justify the expense in rewriting the application for a new platform.
Although ASP classic and ASP.NET share a similar-looking syntax and some common coding conventions, they are very very different from each other. If you tried to simply copy-paste classic ASP code into an ASP.NET application, you might be able to get it to work, but you'd be missing out of a lot of the advantages of ASP.NET Web Forms or ASP.NET MVC (and their respective frameworks, of course).
You can, however, extend the functionality of the existing site with .NET code through web services or COM interop. We have a 10+ year old classic ASP web site and I've used both .NET web services (.asmx) and COM-callable .NET DLLs to enhance our existing application. In both cases, I wrote all of my new business logic in the .NET component and provided a chunky interface to work with the existing ASP page. That allowed my .NET code to be very easily testable and still use our existing (huge) investment in our classic ASP site.
The only approach that has worked for me is to carve of areas of functionality in small slices, and rewrite. "Converting" first, then refactoring seemed like a good idea a few times, but in the end just became horrible messes of code written in ASP.NET instead of ASP - and that added no value.
If you have a site that has distinct areas of functionality, carve one off and start with that (I chose "contact us"). Write it the way you think it should be written - that is, assume your new part is fitting into the end design of your well-written app. If you have to add "hacks" to interface with the old system, make sure they are isolated and commented.
When working on an update, think "can I carve of some of the functionality here into it's own bit?" - if so, convert it then update it. I found that if you insist on keeping the NEW app clean and allow yourself to add small hacks to the OLD app for communication, you get the best results.
This does mean you'll have two separate apps (two IIS web apps) for a while, and can make cookie/url and session management a bit hairy, as well as adding one more deployment concern. To combat this, make sure that you minimize state in your web app (always a good idea anyway), and share state through something other than Session.
If you do this a piece at a time, make the pieces small enough, and have a good design up-front, this works well - at least in my experience, it's the way that works best. Note that my experience may not match reality.
Is it ok to roll your own localization framework? I would be ok using the default .NET localization behavior (i.e., putting text in resource files named a certain way in the assembly), except that we have localized images and text that need to be rendered in DirectX in addition to WinForms and WPF.
I could put form-specific strings in one place and other strings somewhere else, but I think that it makes more sense to keep everything in one place, not to mention it will help to avoid duplicates (for domain values like Yes/No, etc.). It's also possible we may be moving this tool to another platform in the future, so it would be nice to have all the localization information in one platform-agnostic area.
I realize this is a little subjective, but I'm looking for a best practice here...I've worked on projects that take both approaches. Any thoughts?
I have developed systems in which localisation is implemented via database-stored data and metadata. If your app is already making intense use of a fast database backend, you could create a database-backed localisation layer and use it to store localised information, including textual and non-textual data. It has worked great for us in a few ocasions.
Edit. The details won't fit in here, but basically we mirrored the logic of the key/value resource manager that the Windows API or .NET use. We extended that by allowing resources to be grouped into groups, which can be nested arbitrarily. Resource names can be given as, for example, "ClientManagement.MainForm.StatusBar.ReadyMsg", meaning the ready message text to display on the status bar of the main form in the client management user interface. On app startup, a locale setting is read from a config file and a resource manager initialised with it; all the subsequent calls to the resource manager will be using such a locale setting until explicitly changed. We also built an administrative user interface that allowed us to edit the resources stored in the database, and even add new languages. A final comment: data to be localised is not only labels and icons on screen. Option values in combo boxes, for example, also need to be localised.
We implemented a localization using DB backend. We were able to create a great resource editor which allows "translator" end users to dynamically update translations (cannot do that with a resx!). We were also able to support an approval process and group translations by module such that an entire module could be approved for use in a language, or not.
We also decided to implement the localization provider for Asp.Net, which basically does 'automatic' localization with no code by the developer. This was actually the only difficult part of the project as the interface is not well documented. It was hard to debug because it actually runs within Visual Studio host process. We used a web service to decouple the implementation which greatly simplified things. Another good thing is that the translations are automatically cached so the DB is not working as hard. A bad thing is that when your translation service/back end is down and if you do not precompile your asp.net web site, when the user launches a 'new' page, the compiler might decided NOT to translate the page. This behaviour remains (even after the translation service starts up again) until you force a recompile of the site.
Are there any resources with information creating a self contained, reusable module?
I need to create modules that I can drop into projects quickly and easily. An example would be a news module that would contain an admin area, news listing page, It supporting CSS & JavaScript, etc.
Am I smoking my socks or is this even possible?
You need plugins for your application.
I've got a plugin library (in development and in Spanish) that you might use as an example or a starting point. I don't know how good google translate will be but you can check a C# plugin tutorial in http://translate.google.com/translate?hl=es&ie=UTF-8&u=http://www.thealphasite.org/es/sistema_de_plugins_con_c_y_net&sl=es&tl=en
A plugin allows you to plug in :P functionality into your application and, with a proper design, it will allow you to move functionality dinamically from one application to another.
Anyway, plugin just provide with ease of use but require a design specifically thought with them in mind. On the other hand, basic "take this module and use it in another project" is just proper encapsulation and good design. If a module is well designed the it should be able to be ported to another site or application with very little effort.
Keep in mind that, specifically for web, "theming" is a complex subject, that is, adapting your plugin to the way an specific web looks is another step of customization which has to be included into the module itself. You can see an example in the Drupal theming functions and the theming api documentation.
Look at www.allnewsmanager.net, maybe is what you are looking for. It is a reusable module, free and open source.
Not sure about any resources - but I've done this myself by writing a CMS from scratch using a combination of user controls for the modules, and a templating system with common code file which loads said user controls into placeholders.
The templating system allows you to create an aspx file, with a bunch of placeholders (as many as you need) - then you need a database or similar to manage what controls go to what placeholders, on what page. A template can handle many pages.
Downloading and studying the architecture for dotnetnuke can enlighten and give ideas for structuring your own approach, even though it's VB, the data structure is just as interesting.