Asp.net + Silverlight + WCF and n-tier architecture

Coders, I am in process of designing/implementing (yes, both at the same time) my prototype of my own CMS. I use Asp.net, WCF and silverlight. So far I have the following model for my project:

Presentation layer [silverlight & Asp.net/html] > WCF > Business logic > Database

The goal of my model is to make it easy to extent the applic开发者_如何学JAVAation in the future. It will be possible to access the application from any application that can consume my WCF services.

Unfortunately, I have some difficulties implementing my model. It appears to me that if I have three projects in my solution:

Solution:

• -Asp.net [Presentation layer]
• -Silverlight [Presentation layer]
• -WCF [WCF and Business logic]

Then I will have to duplicate many classes both in my presentation layers and my WCF layer.

Here is a scenario: let is say that I have a Post Class in my WCF, which is an implementation of my BL. I would be able to add a new post from my PL, after creating a client instance of my service reference, using a line such as: client.AddPostAsync(post parameters). However, if wanted to retrieve a Post object in my PL by calling a WCF method, then will I have to already have an implementation of a Post class in my PL which is the exact same copy of my Post class in my WCF!

Thus, in the long run, I will end up with many duplicates of classes both in my WCF layer and in my PL. I feel that there is something I don’t understand or maybe I am messing something in my model? Please help!

Indeed you dont have to duplicate classes (with DataContract attribute) from WCF service in Silverlight, they will be simply created automatically when you create a ServiceReference to your WCF service.

Howether they will be very simple basicly store-data-in-fields-classes so I can understand that you might want to create some functional duplicates in Silverlight if you will need some logic behind them. I am using same model in my project and have this issue too.

I think you should plan your architecture ahead knowing this , making those WCF inherited classes more and more looking like DataTransferObject pattern classes, to avoid massive class duplication.