我尝试为仅使用Silverlight UI的数据中心应用程序设置一个干净且灵活的应用程序框架。我希望有严格的关注点分离，并且希望尽可能灵活（例如，稍后交换ORM），同时仍然减少代码量。
我花了几周时间来找出合适的架构，尽管我的最新方法似乎符合我的要求，但我仍然不完全相信这种方式是最好的并且技术上可行的。
这就是我的解决方案浏览器的样子：
- MyCompany.MyApplication.Entities 类库 - 项目，仅包含域（业务）对象，例如客户、地址等。这些都是带有[Serializable]属性的POCO，但没有其他代码。所有属性都标记为虚拟的，以便类可以派生并覆盖属性。 - MyCompany.MyApplication.DataAccess 类库 - 项目，包含nHibernate特定的代码（Sessions）来加载、保存和删除域对象。此项目引用Entities项目以及nHibernate库。 - MyCompany.MyApplication.Core 类库 - 项目，包含业务逻辑，并经常只映射DataAccess项目中的方法，例如GetAllCustomers、SaveCustomer等。它引用Entities项目和DataAccess项目。 - MyCompany.MyApplication.Web Web应用程序 - 项目，托管Silverlight客户端应用程序以及与客户端通信的WCF服务。为了将域对象暴露给客户端，这些类被派生并覆盖所有属性，并标记为[DataMember]属性。它引用Entities项目和Core项目。 - MyCompandy.MyApplication.Silverlight Silverlight 3.0 - 项目，表示用户界面。它仅具有对Web项目公开的WCF服务的服务引用。实际的域对象不可访问，但自动生成的代理类替换了它们。
请告诉我，您对此架构有何看法，是否存在任何冲突！进一步的问题：是否有任何方法可以避免域对象的属性是虚拟的并且需要重写它们以通过WCF使它们可访问？
最好的问候， Daniel Lang
我花了几周时间来找出合适的架构，尽管我的最新方法似乎符合我的要求，但我仍然不完全相信这种方式是最好的并且技术上可行的。
这就是我的解决方案浏览器的样子：
- MyCompany.MyApplication.Entities 类库 - 项目，仅包含域（业务）对象，例如客户、地址等。这些都是带有[Serializable]属性的POCO，但没有其他代码。所有属性都标记为虚拟的，以便类可以派生并覆盖属性。 - MyCompany.MyApplication.DataAccess 类库 - 项目，包含nHibernate特定的代码（Sessions）来加载、保存和删除域对象。此项目引用Entities项目以及nHibernate库。 - MyCompany.MyApplication.Core 类库 - 项目，包含业务逻辑，并经常只映射DataAccess项目中的方法，例如GetAllCustomers、SaveCustomer等。它引用Entities项目和DataAccess项目。 - MyCompany.MyApplication.Web Web应用程序 - 项目，托管Silverlight客户端应用程序以及与客户端通信的WCF服务。为了将域对象暴露给客户端，这些类被派生并覆盖所有属性，并标记为[DataMember]属性。它引用Entities项目和Core项目。 - MyCompandy.MyApplication.Silverlight Silverlight 3.0 - 项目，表示用户界面。它仅具有对Web项目公开的WCF服务的服务引用。实际的域对象不可访问，但自动生成的代理类替换了它们。
请告诉我，您对此架构有何看法，是否存在任何冲突！进一步的问题：是否有任何方法可以避免域对象的属性是虚拟的并且需要重写它们以通过WCF使它们可访问？
最好的问候， Daniel Lang