Orm 支持3层web服务的体系结构

在网上阅读了大量关于最佳实践应用程序设计和模式的文章后，我仍然无法将所有信息合并在一起，并映射到我真正的word应用程序上

我想要一个三层应用程序：

• UI层：
  托管在ASP.net-Webapp中的silverlight应用程序
  
  
• BusinessLogicLayer:
  WCF Services/.NET RIA服务在不同服务器上运行
  
  
• DataAccessLayer：使用类似nHibernate Order的ORM

问题是，我不知道将业务对象放在哪里，以及在哪里填充数据

是否应该有另一个层，包含所有我的业务对象，以便它们可以在所有其他3个层中使用？
或者我应该将它们放在BLL中，并在DAL中调用nHibernate方法——但这样，BLL和DAL之间就会有一个循环依赖关系？ 如果我在DAL中引入“DataAccessObjects”并将所有属性复制到BLL中的BusinessObjects中，这不是“架构过度”吗

感谢您的帮助

致以最良好的祝愿，

---

Daniel Lang

业务对象位于业务层。这些对象由UI层使用，并从数据层调用方法来填充它们自己

通常，层中的对象只调用其自己层中的方法，或者只调用其下面的方法

---

其中一个动机是能够在不改变其他层的情况下替换其中一层。例如，可能有一种不同的方式来呈现UI，它可以使用来自业务层的相同方法。或者，只要新数据层包含与旧数据层相同的方法，就可以更改数据库。

好吧，因为您使用的是WCF，所以您应该有一个只包含接口和数据类的“契约”。这些课程应该对其他人开放。它不应该包含任何逻辑。

好吧，在回顾了整个问题之后，我认为“最佳”解决方案是使用DependencyInjection或IversionOfControl在DAL中使用数据填充业务对象。

业务对象位于公共层

我通常创建一个项目，其中包含业务对象、枚举以及服务器和客户机之间常见的任何内容

---

所有图层都会引用此项目。它不能引用任何其他项目，否则会创建循环引用

事实上，我并不直接使用WCF，而是在“普通”WCF服务之上构建的WCF RIA服务。我的意图是，尽可能保持业务对象的干净，因此创建额外的“管理器”——处理业务对象所有事务的类。