Possible architecture pitfalls

I am currently building a fairly complex CRM / POS system which has the following requirements:

1. System needs to be able to be installed on a single machine (PC)
2. System needs to be able to be installed on 1 machine that can act as a server, and be accessed by several client machines (local network, wired and wireless)
3. System needs to be able to run without an internet connection

Once the system is launched, the next phase will be to create a web based version. The UI is paramount and needs to be as slick as possible as it is for a very image conscious industry.

The architecture I have settled on is as follows:

• Sql Server 2008 Express DB
• Linq-To-Sql data layer
• WCF services exposing linq data layer
• WPF for the front end

This should support all 3 requirements, and I am hoping provide a fairly easy port from WPF to Silverlight for the web based phase 2.

My question is, are there any issues with the architecture I have chosen? I have u开发者_StackOverflow中文版sed asp.net and Windows Forms extensively however have little experience in WPF (chosen it for the graphical capabilities). Are there any issues with Linq-To-Sql binding in WPF via WCF?

A few thoughts:

If you're planning a port from WPF to Silverlight, I'd recommend following a Separated Presentation pattern like MVVM. Depending on the complexity of the UI, following the PRISM guidance and multi-targetting your development for both WPF and SL might save you some time in the long run. Or, you might consider forgoing WPF entirely and develop an out-of-browser SL app from the start -- the two XAML dialects and toolkits are getting ever closer. This might complicate your "disconnected" scenarios, however.

Bear in mind that the design of your services (for low-chattiness and minimal data transfer) will be a factor in how successful the web-based version will be.

As you need a web based solution later, why not install IIS on the single pc, so that your single machine solution is also “web based”.

You can then use Silverlight from day one. However do you need to do anything in the UI on the Single PC system that can’t be done by Silverlight?

Would you rather get the Single PC version out fast, then have the pain of porting to a web deployed solution, or do you want the pain at the start?

I looked into this recently and came to the conclusion that the Entity Framework sat better between the database and WCF/WPF. The article The Entity Framework In Layered Architectures was important in my decision making process. It's also possibly better to have a DB agnostic approach initially.

Having now built most of the application (DB->EF->WPF desktop application) I'm still happy that I went with the EF. The EF does most of the grunt work for me and I think it maps really well between relational and object oriented.

If you're intending on publishing the web version using silverlight then I would take heed of the advice to start by building both versions as part of your architecture. It is hard to do this retrospectively. Refer to Code reuse in WPF and Silverlight 2.

In either case I'd include validation of all requirements before going much further. Build a simple proof of concept application that validates that all of your three requirements can be met with the architecture you have chosen.