architecture - 一般 N 层架构问题

Question

在 N 层应用程序中，您应该有一个业务逻辑层和一个数据访问层。仅使用两个程序集:BusinessLogicLayer.dll 和 DataAccessLayer.dll 来处理所有这些逻辑是否不好？您实际上如何表示这些层。在我看来，拥有一个包含类的 BusinessLogic 类库似乎很愚蠢:CustomerBusinessLogic.cs、OrderBusinessLogic.cs 等，每个类都在 DataAccessLayer 类库中调用其适当命名的表亲，即 CustomerDataAccess.cs、OrderDataAccess .cs.

我想使用 MVP 创建一个 Web 应用程序，它看起来不像这样简单明了。关于业务逻辑应该放在 MVP 中的什么位置有很多意见，我不确定我是否找到了一个真正好的答案。

我希望这个项目易于测试，并且我会尽力遵守 TDD 方法。我打算使用 MSTest 和 Rhino Mocks 进行测试。

我正在为我的架构考虑如下内容:

我会使用 LINQ-To-SQL 与数据库对话。 WCF 服务为业务逻辑层定义数据契约接口(interface)。然后将 MVP 与 ASP.NET 窗体一起用于 UI/BLL。

现在，这不是这个项目的开始，大部分 LINQ 的东西已经完成，所以它被卡住了。 WCF 服务将替换现有的 DataAccessLayer 程序集，UI/BLL 将替换 BusinessLogicLayer 程序集等。

这在我的脑海中是有道理的，但它已经很晚了。任何走过这条路的人都有任何指导吗？好的链接？警告？

谢谢!

Answer 1

the way I've seen it, to have a BusinessLogic class library containing classes like: CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc

哎呀。获取并阅读 Scott Ambler 的“构建有效的对象应用程序”。您的方法不会，而且是一场维护噩梦 - 没有对象。

I'd use LINQ-To-SQL to talk to the database. WCF services to define data contract interfaces for the business logic layer. Then use MVP with ASP.NET Forms for the UI/BLL.

是的。人为地使应用程序比必须的更复杂和更慢的好方法。扔掉完整的 WCF 服务——它们有什么用？ WCF 用于 SOA，而 SOA 存在于用户界面中(即它是一个信任边界和供另一个应用程序使用的用户界面)。除非你有那个要求……引入额外的缓慢技术只是有开销是愚蠢的。

The WCF service would replace the existing DataAccessLayer assembly

The Daily WTF - 当您使用 LINQ to SQL 时，您有一个 DAL 程序集到底有什么用？ LINQ to SQL(运行时)是您的 DAL。

Anyone that's traveled down this path have any guidance? Good links?

您基本上选择了我能想到的所有反模式 - 维护噩梦，过度设计，其中包含大量无用的技术。您将分层技术强制纳入分层架构。

阅读我提到的那本书。