一般N层体系结构问题

在一个N层应用程序中，你应该有一个业务逻辑层和一个数据访问层。简单地有两个程序集：BusinessLogicLayer.dll和DataAccessLayer.dll来处理所有这些逻辑是不是很糟糕？你如何真正代表这些图层。看起来很傻，有一个BusinessLogic类库包含像CustomerBusinessLogic.cs，OrderBusinessLogic.cs等类，每个类调用它们在DataAccessLayer类库中相应命名的表亲，即CustomerDataAccess.cs，OrderDataAccess的.cs。一般N层体系结构问题

我想创建一个使用MVP的Web应用程序，它看起来并不像这样被切割和干燥。关于业务逻辑应该放在MVP中的位置有很多意见，我不确定我是否找到了非常好的答案。

我希望这个项目很容易测试，我尽可能的坚持TDD方法论。我打算使用MSTest和Rhino Mocks进行测试。

我在想的东西像我的架构如下：

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

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

这种情况在我的脑海中是有道理的，但它确实很晚。任何沿着这条路走过的人都有任何指导？良好的联系？警告？

谢谢！

来源

2010-03-19 mikesigs

我已经看到了它的样子，有含类像 BusinessLogic类库： CustomerBusinessLogic.cs， OrderBusinessLogic.cs等

哎哟。获取并阅读Scott Ambler的“构建可以工作的对象应用程序”。你的方法不是，而且是维护强光 - 没有任何物体。

我会使用LINQ-To-SQL与数据库进行通信。 WCF服务来定义数据业务合同接口逻辑层。然后使用MVP和ASP.NET 用于UI/BLL的表单。

是。让应用程序人为地变得更加复杂和慢的好方法。抛出完整的WCF服务 - 它们的用途是什么？ WCF用于SOA，并且SOA驻留在用户界面中（即，它是用于其他应用程序的信任boudary和用户界面）。除非你有这个要求....引入额外的慢技术只是有开销，这是愚蠢的。

WCF服务将取代现有的装配DataAccessLayer

每日跆拳道 - 你到底你有没有当您使用LINQ to SQL的一个DAL组件？ LINQ to SQL（运行时）是您的DAL。

任何人走过这条路有任何指导？良好的联系？

你基本上选择了我能想到的每个反模式 - 维护噩梦，过度设计了大量无用的技术。您将图层技术强制为分层架构。

阅读我提到的这本书。

来源

2010-03-19 06:15:23 TomTom

谢谢汤姆汤姆，无视我的职位，而不是我的计划。我会拿起你提到的那本书的副本。 – 2010-03-19 06:23:58

谢谢你的回答。这有点严厉，但我认为它是一个迹象，表明你有如此强烈的感情。但请注意，这不是我的设计。我在想WCF将是一个好方法。这似乎是合适的，但你是对的，这会增加不必要的开销。要回答您的“每日WTF”，我们有一个包含我们的实体的LINQ程序集，并且DAL包含我们的LINQ层的API。但是，很多BLL逻辑似乎只是调用DAL的存根。这些层可能会合并成一个单一的服务层（因此我想到了WCF）*叹息* – mikesigs 2010-03-19 13:16:26

答案是诚实和正确的，答案中的任何苛刻似乎都是有保证的。为什么它需要使用通信渠道？为什么你的业务逻辑不在你的模型对象中？当它应该是你的透明持久域模型时，为什么你要坚持把LINQ to SQL称为“DAL”？这里面有太多的东西，只要有人知道，大部分都没有理由，这一切在你的脑海中可能是有道理的，但我无法理解为什么你想要处理所有那些东西。 – yfeldblum 2010-03-21 02:55:35

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

来源

2010-03-21 02:27:42 bloparod

一般N层体系结构问题

回答

相关问题