一般的N层架构问题

Question

在N-Tier应用程序中，您应该有一个业务逻辑层和一个数据访问层。但是，仅仅拥有两个程序集：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 Forms进行UI/BLL。

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

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

谢谢！

- mikesigs

Answer 1

据我所见，要有一个包含类似于CustomerBusinessLogic.cs、OrderBusinessLogic.cs等类的BusinessLogic类库。

哎呀，去读一下Scott Ambler的《构建有效的对象应用程序》吧。你的方法没有使用对象，是维护上的噩梦。

我会使用LINQ-To-SQL与数据库通信。WCF服务定义业务逻辑层的数据合同接口。然后在UI/BLL中使用MVP与ASP.NET Forms。

是的，这是让应用程序人为复杂和比必要更慢的好方法。放弃完整的WCF服务——它们是干什么用的？WCF用于SOA，而SOA位于用户界面中（即它是信任边界和另一个应用程序使用的用户界面）。除非您有这个要求……否则引入额外的缓慢技术只会增加开销。

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

当您使用LINQ to SQL时，您为什么需要DAL程序集？LINQ to SQL（运行时）就是您的DAL。

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

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

读一下我提到的那本书吧。

- TomTom

---

谢谢Tom Tom，除了我的计划之外，请忽略我的帖子。我会去买你提到的那本书。 - Pieter Germishuys

谢谢你的回答。虽然有点严厉，但我想这表明了你的强烈感受。然而，请注意这不是我的设计。我认为WCF可能是一个不错的选择。看起来很合适，但你说得对，它会增加不必要的开销。回答你的“每日WTF”，我们有一个包含实体的LINQ程序集和DAL包含我们对LINQ层的API。但是很多BLL逻辑似乎只是调用DAL的存根。这些层可能可以合并成一个单一的服务层（因此我考虑使用WCF。叹气）。 - mikesigs

答案诚实而正确，回答中的任何严厉之处似乎都是有道理的。你需要一个服务层干什么？为什么它需要使用通信渠道？为什么你的业务逻辑不在你的模型对象中？为什么你坚持把LINQ to SQL称为“DAL”，当它应该是你透明持久化领域模型呢？里面的东西太多了，就目前在SO上的任何人来看，大部分东西都没有理由存在。这一切可能在你的脑海中是有意义的，但我无法理解为什么你想要处理那些琐碎的事情。 - yfeldblum

是时候说实话了。这不是我的设计。我同意到目前为止所做的每一个严厉评论。在我的办公室里，我被称为"麻烦制造者"，因为我总是发表自己对如何改变/改进设计的意见，但通常会被忽视，因为更改可能会影响截止日期或者太过激烈或困难。 "服务层" 实际上是我曾经有过的一个想法的扭曲形式。我更愿意将 DAL 视为一组存储库，将 BLL 视为适当的领域模型或一组控制器/演示文稿。请帮助我理解为什么这是糟糕的设计，以便我可以提供合适的论据。 - mikesigs

Answer 2

关于XXXBusinessLogic，它们很快就会变成神对象。在你的领域中考虑有意义且代表行为的对象，而不是BusinessLogic "对象"。这种类型的"对象"最终将执行XXX所有工作，并且确实是一场维护噩梦。

- bloparod