我意识到已经有很多关于n层设计的帖子，这可能是我思考的事情和围绕圈子，但我现在都很困惑，并希望得到社区的一些清晰请。
我正在尝试将我创建的项目（并且在架构上没有很好地设计开始）分成不同的层（每个层都在他们自己的项目中）：
UI 应该只调用逻辑层来获取其内容
Business Objects 不应该调用或引用任何其他内容，只是存储数据的方式
逻辑 / BUSINESS 图层应包含在系统中获取，创建，更新，删除（CRUD）对象的所有方法，并且可以同时引用BO和DAL。它会将业务逻辑应用于操作，然后将实际的CRUD委托给DAL。
DAL 只会对数据库执行CRUD操作。它会引用BO，因为它会为Get等返回它们。
我的问题是Logic类只应调用它们的等效DAL类而只调用逻辑类吗？换句话说，CompanyLogic类应该只调用CompanyDAL类。因此，如果它想通过ID获取A Client对象，则会调用ClientLogic.GetClientByID(int)而不是ClientDAL.GetClientByID(int)。
我认为它应该留在自己的层面的原因是：
似乎放松了项目之间的耦合
逻辑怎么样，如果得到一个客户端对象有一些逻辑验证（可能不是最好的例子，但希望它能得到重点）。
修改
我不确定我的设计是不是很糟糕，但目前BUSINESS层有很多类，包括ClientBULL和CompnayBULL，这两个类都互相调用。我为每个类使用一个接口，并有一个工厂来构建对象以尝试减少任何耦合，但由于在两个类中调用方法，它们现在彼此之间不能存在。这是一个坏主意吗？
答案 0 :(得分：4)
嗯，这是我对你的设计的评论：
逻辑是一个错误的名称，基本上是分配给抽象持久性的层。我可能会把它称为“存储库”或“持久性”或DAO（数据访问对象）而不是“逻辑”，这是不明确的，绝对意味着任何。
如果您真的想要将业务层与DAL分离，那么您的逻辑层应该只接受DAL的接口，而不是具体的DAL类。
关于验证应该驻留在哪里，有两种思路。有些完全没问题，验证位于UI层;其他人宁愿抛出异常或从业务层传递消息。无论你走哪条路，只要保持一致，不要在多个地方重复验证，你就没事了。
继续尝试编码可能是我能给你的最佳建议。通过它可以很好地思考它，但是有一点你需要在编码时看到它，然后才会出现细微的怪癖和陷阱。无论你想出什么样的原型，对于你的开发和设计所带来的方向肯定是有价值的。
古德勒克！
<强>更新
重新编辑：在同一个命名空间或程序集中，对具体类的调用绝对没问题。我认为你需要为业务逻辑设置接口会过于复杂 - 我的意思是你应该遵循多套规则吗？
我相信保持简单并遵循YAGNI。在有两个以上的类要实现/已经实现该接口之前，不要创建接口（尽管DAL总是例外）。