R – n-tiered architecture with Silverlight, WCF and nHibernate

I try to set-up a clean and flexbible application-framework for data-centric applications with silverlight-only UI. I want to have a strict seperation of concerns, and want to be as flexible as possible (e.g. exchange the ORM later) while still reducing the amount of code.

It took me weeks to figure out an appropriate architecture, and although my latest approach seems to fit my requirements I'm still not completely convinced, that this way will be the best and is technically possible.

Here is how my solutions-explorer looks like:

• MyCompany.MyApplication.Entities
  Class library – project, which contains only the domain (business) objects, such as Customers, Adresses, etc. These are POCOs with the [Serializable] – attribute, but do not any other code. All properties are marked as virtual, so that classes could derive and overwrite the properties.

• MyCompany.MyApplication.DataAccess
  Class library – project, which contains the nHibernate – specific code (Sessions) to load, save and delete the domain objects. This project has references to the Entities-project and also to the nHibernate-libraries.

• MyCompany.MyApplication.Core
  Class library – project, which contains the business logic, and often just maps the methods form the DataAccess – project, such as GetAllCustomers, SaveCustomer, etc.
  It has references to the Entities-project and the DataAccess-project.

• MyCompany.MyApplication.Web
  Web-application – project, which hosts the silverlight-client-app and also the WCF-services to communicate with the client-side. To expose the domain-objects to the client-side, these classes are derived and all the properties are overwritten and marked with the [DataMember] – attribute. It has references to the Entities-projects and the Core-projects.

• MyCompandy.MyApplication.Silverlight
  Sivlerlight 3.0 – project, which represents the userinterface. It has only service-references to the WCF-Services exposed by the Web-project. The actual domain-objects aren't accesssible, but the auto-generated proxy-classed replace them.

Please tell me, what do you think about this architecture, and if there are any conflicts! Further question: Is there any way, to avoid the properties of the domain-objects being virtual and the need to overwrite them in order to make them accessible trough WCF?

Best regards,
Daniel Lang