Choosing the right .NET architecture. WCF? WPF/Forms, ASP.NET (MVC)?

Question

I’m in the situation that I have to design and implement a rather big system from the bottom. I’m having some (a lot actually) questions about the architecture that I would like your comments and thoughts on.

I don’t hope that I’ve written too much here, but I wanted to give you all an idea of what the system is.

Quick info about the applications, read if you want: I can’t share much detail about the project, but basically it’s a system where we offer our customer a service to manage their users. We have a hotline where the users call and our hotline uses an (windows) application (intranet) to manage the user’s data, etc. The customer also has a web application where they can see reports, information about their business and users, and the ability to modify their data. Modifying data is not just user data like address and so, but also information about the products/services the user has, which can be complicated.

The applications will be built on Microsoft .NET Framework 4, with a MS SQL Server 2008 database. There will be a few applications that have to access this database, such as:

• Intranet application (used by us and our hotline)
• Customer web application type 1
• Customer web application type 2
• Customer web application type n different applications)
• …

Now my big problem is what .NET parts I should use for such a system. For the “backend” I’ve considered using Windows Communication Foundation: Would WCF be a good choice?

The intranet application will be an application that has to edit lots of records in the database. It has to be easy to navigate using the keyboard (fast to work with). Has a feature such as “find customer, find that, lookup this, choose this and update that”. What would be the best choice to develop this application in? Would it be WPF or good old Windows Forms? I don’t need all of the fancy graphics features in WPF, like 3D, but the application has to look nice (maybe something like the new Visual Studio/Office tools).

And the same question goes for the web pages. They have much the same work to do, but not as many features as the intranet application, and not the same amount of data (much less).

That is my questions for now. I’m hoping to get a discussion going that will open my eyes to some of these technologies, helping me decide architecture to go with.

I would like to say thanks in advance, and let you all know that any thoughts will be much appreciated.

---

Edit 1: It seems like many agree that we should use WCF. When introducing an ORM mapper in the data layer, and a service layer using WCF, there must be a performance hit? Do you have any comments on this?

Another question that keeps popping up is how we handle authentication and roles. The intranet application has “master” access (no limitations). However, when a customer retrieves information from the web application about their users, what is returned depends on what their “service level” is and a few other parameters related to the customer. What is the best way to handle this? Are there any patterns/ best practices?

Answer 1

This design looks eminently feasible.

WCF is a good candidate for the service layer, it's nice to see some ORM-age going on and you have a good reason to have a form-based and a web-based UI.

WPF can (essentially) behave like a Windows Form. However, MS recommend it over Win Forms if you are writing something new.

ASP.NET MVC is a great candidate for web-based stuff - the pages are stateless and you have much more control over the page.

Check out individual "WPF VS WinForms" type discussions for more detail.

Answer 2

Desktop UI technology

WPF is incredibly powerful and is unquestionably best choice for the type of application you describe. If your team has no WPF experience figure on a several month learning curve, but the long-term benefits of increased productivity and maintainability make it well worth it. The only reason you might consider anything but WPF is if you have a tight deadline and your team already knows some other technology very well. Even in that case, I would consider developing the WPF version in parallel and consider the other version as just a prototype.

Some people are doing desktop development using Silverlight instead of WPF on the theory that they should use one technology instead of two. I don't agree with that argument: The two technologies are similar enough that skills and code transfer extremely well, WPF currently has many very useful features missing in Silverlight, and as Silverlight gains those features it tends to copy what is good from WPF. So in the long run any effort spent and code created while devloping WPF applications will not be wasted.

Also note that WPF can run in a browser just as well as Silverlight. When I create web applications for clients that I know will be running Windows I choose WPF over Silverlight. I am currently in the process of converting a bunch of Windows apps into WPF web apps for easier deployment.

Web UI technology

You'd be a fool to use ASP.NET MVC on a web application if you could possibly use Silverlight. Things that takes days in ASP.NET MVC take hours or minutes on Silverlight. Things that take days in Silverlight take years in ASP.NET MVC.

Silverlight's market penetration is currently around 50% and growing at 2-3% per month, and it will run on 99% of desktop machines. By next year penetration may be at 85% or higher. You have to weigh the risk that a few users won't download Silverlight and won't access your application against the risks associated with ASP.NET MVC: With ASP.NET MVC your application will cost a lot more to develop, take longer to get to market, have fewer features and less "richness".

That said, if there was a contract I really, really, really wanted and the client wasn't comfortable using Silverlight, I would probably fall back to ASP.NET MVC as my second choice. But only if the web section of the application was relatively small.

Communications technology

WCF is a good choice for serving up your data. It is currently better than the competition, plenty fast, and integrates well with Silverlight, XBAP, and WPF. If you have no compelling reason to choose a different web services technology I would go with WCF.

As far as efficiency goes, WCF's binary formatter is just about as efficient as anything you will find, and is more efficient than typical direct database access protocols such as TDS for the usage patterns you will encounter. If you have to use the SOAP formatter for compatibility you will lose some bandwidth in the conversion to XML but otherwise it is relatively efficient.

I use a data layer called "Emerald Data Foundation" that I built myself and plan to open-source in the next few months. It uses the same objects on the web service and on the client and behaves identically whether or not it is connected to a back-end database. This works very well because you hardly realize there is a communications layer at all. Such an approach makes the data layer extremely simple.

Emerald Data Foundation also has a role-based access control mechanism that allows clients to be granted access to data based on relationships between data objects, so that, for example, a person can access only their own customer data. This is enforced at the data layer so no UI layer development can accidentally expose data that shouldn't be seen or make unauthorized updates.