具有Silverlight、WCF和nHibernate的n层体系结构

我尝试为仅使用silverlight UI的以数据为中心的应用程序建立一个干净的flexbible应用程序框架。我希望严格分离关注点，并希望尽可能灵活（例如，稍后交换ORM），同时减少代码量

我花了数周时间才找到一个合适的体系结构，尽管我的最新方法似乎符合我的要求，但我仍然不完全相信这种方法是最好的，而且在技术上是可行的

以下是我的解决方案资源管理器的外观：

• MyCompany.MyApplication.Entities
  类库-项目，仅包含域（业务）对象，如客户、地址等。这些是具有[Serializable]属性的POCO，但不包含任何其他代码。所有属性都标记为虚拟，以便类可以派生和覆盖这些属性

• MyCompany.MyApplication.DataAccess
  类库-项目，其中包含用于加载、保存和删除域对象的nHibernate特定代码（会话）。该项目引用了Entities项目和nHibernate库

• MyCompany.MyApplication.Core
  类库-project，它包含业务逻辑，通常只映射DataAccess-project中的方法，例如GetAllCustomers、SaveCustomer等。 它引用了Entities项目和DataAccess项目

• MyCompany.MyApplication.Web
  Web应用程序-project，它托管silverlight客户端应用程序和WCF服务，以便与客户端通信。为了向客户端公开域对象，将派生这些类，并覆盖所有属性并用[DataMember]-属性标记。它引用了实体项目和核心项目

• MyCompandy.MyApplication.Silverlight
  Sivlerlight 3.0-项目，表示用户界面。它只有对Web项目公开的WCF服务的服务引用。实际的域对象是不可访问的，但自动生成的代理类将替换它们

请告诉我，你对这个架构有什么看法，如果有任何冲突！进一步的问题：是否有任何方法可以避免域对象的属性是虚拟的，并且需要覆盖它们以便通过WCF访问它们

致以最良好的祝愿，

---

Daniel Lang

Daniel，你不能回避虚拟财产的nhiberante要求。你考虑过使用Dto吗？

我实际上不明白，使用DataTransferObjects有什么好处？据我所知，它们“只是”封装了我的BusinessObjects？当您需要修改业务对象时，尤其是当您添加或删除属性时，会带来好处。当您更改实体/业务/域对象时，您的web服务合同将更改，从而破坏您的web应用程序。拥有DTO允许您更改实体，同时允许依赖于webservice的应用程序无需更改即可运行。看看这些问题希望这些帮助谢谢！读完这些文章后，我很害怕为什么我以前还没有听说过DTO的优点！伟大的