Architecture 一般N层体系结构问题

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

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

我希望这个项目是易于测试的，我正试图坚持TDD方法论，尽我所能。我打算使用MSTest和rhinomock进行测试

我在为我的架构考虑以下内容：

我将使用LINQtoSQL与数据库通信。WCF服务为业务逻辑层定义数据契约接口。然后将MVP与ASP.NET表单一起用于UI/BLL

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

这种想法在我看来是有道理的，但现在已经很晚了。沿着这条路走的人有什么指引吗？好链接？警告

谢谢

在我看来，有一个 包含 课程包括： CustomerBusiness Logic.cs， OrderBusinessLogic.cs等

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

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

对。这是一个很好的方法，可以人为地使应用程序比必须的更复杂、更慢。扔掉完整的WCF服务-它们是为了什么？WCF是面向SOA的，SOA存在于用户界面中（即，它是一个信任边界，是另一个应用程序使用的用户界面）。除非你有这个要求。。。。引入额外的只会带来开销的慢技术是愚蠢的

WCF服务将取代 现有DataAccessLayer程序集

每日WTF-当您使用LINQtoSQL时，DAL程序集究竟用于什么？LINQtoSQL（运行时）是您的DAL

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

你基本上选择了我能想到的每一个反模式——维护噩梦，用大量无用的技术过度设计。您可以将层技术强制应用到分层体系结构中

---

阅读我提到的那本书。

关于XXX业务逻辑，它们很快就会变得很好。考虑在您的领域中代表行为的有意义的对象，而不是在BusinessLogic“对象”中。这些“对象”将完成XXX的所有工作，是的，它们是维护的噩梦。

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