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

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:

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 i开发者_Python百科nformation 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?

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.

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.

Have you considered Silverlight + RIA Services? -- it's a natural choice for an n-tier system with a rich user interface. You could use it for both the intranet and client-facing applications.

As Sohnee mentioned above, I think your logical architectural approach is pretty solid and I think WCF is "the choice". I'm sure you'll get your share of opinions on presentation technologies and ORM. I'll offer a couple of items on the service layer, which is where I spend a lot of my time in applications very similar to yours:

• If you haven't already, start looking at AppFabric. It's where Microsoft is going with hosting WCF services and provides you a lot of benefits such as high-speed instrumentation and service management that you don't get out of the box with WCF now.
• Think about what type of protocol (and consequently WCF bindings) you'll be able to use based upon your network infrastructure and those of your business partners. If you can use TCP as a high-speed transport, you'll be in great shape, as long as it will work with your network.
• Consider integrating MSMQ into your logical architecture to provide queuing and guaranteed delivery. Juval Lowy has some excellent materials on MSMQ integration in his WCF books.
• Start thinking now about your service interfaces and service versioning strategy. Decisions made early on in these areas become nearly immutable once they are shared with business partners.
• With multiple business partners involved, think about how you're going to secure these services. Microsoft's P&P group just issued some pretty good guidance on claims-based identity and access control that might be really useful to you based upon your integration scenarios.

Hope this helps. Feel free to post a follow-up if you need more info.

If your team doesn't already have experience with WPF, I would recommend sticking with WinForms for the desktop client, assuming you have schedule pressure (and what project doesn't?) WPF is extremely powerful, but it also has a steep learning curve. I've been using it for relatively small, low-visibility projects and it's given me the freedom to really learn how the technology should be used rather than trying to hack together something together as if it were just WinForms with prettier controls.

I don't have much experience with WCF, but my understanding is that there is a lot of learning curve there, as well. As with WPF, it's a matter of what your team knows and how much time you're able to invest in learning a new technology.

I would start from defining the functional requirements as they are likely to shape your architecture. You mentioned about customer applications changing data but indirectly -- via some approval system. I think one of the most important thing here is how will you represent that changes waiting for approval.

If this is only a data-entry application, you can simply build few screens and live with it. It would be the simplest thing that can work.

On the other hand, if reasons why data changes are valuable for the business, I would consider building a solid domain model first. And then a layer of commands atop of it. Customer application would issue commands for data changes like 'Give user Xxx a pay raise' which will be approved and then processed. Such commands would be a first-class citizens in you architecture.