在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程序集等。
这种方式在我的脑海中是有道理的，但它变得非常晚。任何沿着这条路走下去的人都有指导吗？好的链接？警告？
谢谢！
答案 0 :(得分：3)
我看到它的方式，有一个 包含的BusinessLogic类库 课程如： CustomerBusinessLogic.cs， OrderBusinessLogic.cs等
哎哟。阅读并阅读Scott Ambler的“构建对象应用程序”。你的方法不是，而且是一个维护工作 - 没有对象。
我会使用LINQ-To-SQL与之交谈 数据库。 WCF服务定义数据 合同的业务接口 逻辑层。然后在ASP.NET中使用MVP UI / BLL的表单。
是。使应用程序人为地更复杂和更慢的好方法。抛弃完整的WCF服务 - 它们的用途是什么？ WCF用于SOA，SOA存在于用户界面中（即，它是一个信任boudary和另一个应用程序要使用的用户界面）。除非你有这个要求......引入额外的慢速技术是非常愚蠢的。
WCF服务将取代 现有的DataAccessLayer程序集
每日WTF - 当您使用LINQ to SQL时，您有什么DAL程序集？ LINQ to SQL（运行时）是你的DAL。
任何走过这条道路的人 有什么指导吗？好的链接？
你基本上选择了我能想到的每一个反模式 - 维护噩梦，在那里过度设计了大量无用的技术。您将层技术强制为分层架构。
阅读我提到的那本书。
答案 1 :(得分：0)
关于XXXBusinessLogic，它们很快成为God Objects。考虑在您的域中有意义的对象表示行为，而不是在BusinessLogic“对象”中。这些“对象”将结束执行XXX的所有工作，是的，它们是维护的噩梦。