我尝试使用仅支持Silverlight的UI为以数据为中心的应用程序设置一个干净且灵活的应用程序框架。我希望对问题进行严格的分离，并希望尽可能灵活（例如，稍后更换ORM），同时减少代码量。
我花了几周的时间才找到合适的架构，虽然我的最新方法似乎符合我的要求，但我仍然不完全相信，这种方式将是最好的并且在技术上是可行的。
以下是我的解决方案 - 资源管理器的外观：
MyCompany.MyApplication.Entities
类库 - 项目，它只包含域（业务）对象，例如客户，地址等。这些是具有[Serializable]属性的POCO，但不包含任何其他代码。所有属性都标记为虚拟，因此类可以派生并覆盖属性。
MyCompany.MyApplication.DataAccess
类库 - 项目，它包含用于加载，保存和删除域对象的nHibernate特定代码（Sessions）。该项目引用了Entities-project和nHibernate-libraries。
MyCompany.MyApplication.Core
类库 - 包含业务逻辑的项目，通常只是映射DataAccess项目的方法，如GetAllCustomers，SaveCustomer等。
它引用了Entities-project和DataAccess-project。
MyCompany.MyApplication.Web
Web应用程序 - 项目，它承载silverlight-client-app以及与客户端通信的WCF服务。要将域对象公开给客户端，将派生这些类，并使用[DataMember] - 属性覆盖并标记所有属性。它引用了实体项目和核心项目。
MyCompandy.MyApplication.Silverlight
Sivlerlight 3.0 - 项目，代表用户界面。它只有对Web项目公开的WCF服务的服务引用。实际的域对象是不可访问的，但自动生成的代理分类会替换它们。
请告诉我，您如何看待这个架构，以及是否有任何冲突！进一步的问题：有没有办法，以避免域对象的属性是虚拟的，并且需要覆盖它们以便通过WCF访问它们？
祝你好运， Daniel Lang
答案 0 :(得分：1)
丹尼尔，你不会绕过虚拟财产的nhiberante要求。你有没有想过使用Dto？