一般 N 层架构问题答案

【问题标题】：General N-Tier Architecture Question一般 N 层架构问题
【发布时间】：2010-03-19 05:55:10
【问题描述】：

在 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 服务为业务逻辑层定义数据契约接口。然后将 MVP 与 ASP.NET 表单一起用于 UI/BLL。

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

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

谢谢！

【问题讨论】：

标签： architecture tdd mvp n-tier-architecture

【解决方案1】：

我所看到的，拥有一个 BusinessLogic 类库包含类如： CustomerBusinessLogic.cs, OrderBusinessLogic.cs 等

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

我会使用 LINQ-To-SQL 与数据库。用于定义数据的 WCF 服务业务的合约接口逻辑层。然后将 MVP 与 ASP.NET 一起使用 UI/BLL 的表单。

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

WCF 服务将替换现有的 DataAccessLayer 程序集

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

任何走过这条路的人有什么指导吗？好的链接？

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

阅读我提到的书。

【讨论】：

谢谢汤姆汤姆，除了我的计划之外，请忽略我的帖子。我去拿你提到的那本书。
感谢您的回答。这有点刺耳，但我想这表明你有如此强烈的感情。但是，请注意这不是我的设计。我认为 WCF 将是一个不错的选择。看起来它很合适，但你是对的，它会增加不必要的开销。为了回答您的“每日 WTF”，我们有一个包含我们的实体的 LINQ 程序集，而 DAL 包含我们到 LINQ 层的 API。但是很多 BLL 逻辑似乎只是调用 DAL 的存根。这些层可能会合并为一个服务层（因此我想到了 WCF。sigh
答案诚实而正确。答案中的任何严厉似乎都是有道理的。你需要一个for的服务层吗？为什么需要使用通信渠道？为什么你的业务逻辑不在在你的模型对象中？当 LINQ to SQL 应该是您的透明持久域模型时，您为什么坚持将其称为“DAL”？那里的东西太多了，据 SO 上的任何人所知，大部分都没有理由。这一切在您的脑海中可能都是有道理的，但我无法理解您为什么要处理所有这些琐事。
是时候诚实一些了。这不是我的设计。我同意迄今为止所做的每一个严厉的声明。在我的办公室里，我被称为讨厌的干扰者，因为我总是就如何改变/改进设计发表意见，但我经常被忽视，因为这些改变要么影响截止日期，要么过于激烈或困难。 “服务层”实际上是我曾经的一个想法的混蛋。我更愿意将 DAL 视为一组存储库，而将 BLL 视为适当的域模型或一组控制器/演示者。请帮助我理解为什么这是糟糕的设计，以便我提供合适的论据。

【解决方案2】：

关于XXXBusinessLogic，他们很快就变成了God Objects。考虑在您的领域中有意义的表示行为的对象，而不是在 BusinessLogic“对象”中。这些“对象”将结束为 XXX 执行所有工作，是的，它们是维护的噩梦。

【讨论】：