I am trying to set up a clean and flexible application platform for data-oriented applications with the silverlight user interface. I want to have a strict separation of problems and want to be as flexible as possible (for example, exchange ORM later), while still reducing the amount of code.
It took me weeks to figure out the appropriate architecture, and although my last approach seems to fit my requirements, I'm still not completely convinced that this method will be the best and technically possible.
Here's what my solution explorer looks like:
MyCompany.MyApplication.Entities
Class library - a project that contains only domain (business) objects, such as clients, addresses, etc. These are POCOs with the [Serializable] attribute, but do not contain any other code. All properties are marked as virtual, so classes can display and overwrite properties.
MyCompany.MyApplication.DataAccess
Class library - a project containing nSibernate (Session) code for loading, saving and deleting domain objects. This project has links to Entities-project, as well as nHibernate libraries.
MyCompany.MyApplication.Core
A class library is a project that contains business logic, and often simply displays methods from a DataAccess project, such as GetAllCustomers, SaveCustomer, etc. It has links to the Entities-project and DataAccess project.
MyCompany.MyApplication.Web
A web application is a project that hosts the silverlight-client-app, as well as WCF services for communicating with the client side. To expose client-side domain objects, these classes are displayed and all properties are overwritten and marked with the [DataMember] attribute. It has links to the projects "Objects" and "Main projects".
MyCompandy.MyApplication.Silverlight
Sivlerlight 3.0 is a user interface project. It has only service links to WCF services opened by a web project. Actual domain objects are not available, but automatically generated proxy classes replace them.
Please tell me what you think about this architecture, and if there are any conflicts! A further question: is there a way to avoid the properties of virtual domain objects and the need to rewrite them to make them available through WCF?
Regards, Daniel Lang
source share