一般 N 层架构问题
在 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 程序集等。
这在我看来是有道理的，但已经晚了。有走过这条路的人可以提供指导吗？好的链接吗？警告？
谢谢！
In an N-Tier app you're supposed to have a business logic layer and a data access layer.
Is it bad to simply have two assemblies: BusinessLogicLayer.dll and DataAccessLayer.dll to handle all this logic? How do you actually represent these layers. It seems silly, the way I've seen it, to have a BusinessLogic class library containing classes like: CustomerBusinessLogic.cs, OrderBusinessLogic.cs, etc. each calling their appropriately named cousin in the DataAccessLayer class library, i.e. CustomerDataAccess.cs, OrderDataAccess.cs.
I want to create a web app using MVP and it doesn't seem so cut and dry as this. There are lots of opinions about where the business logic is supposed to be put in MVP and I'm not sure I've found a really great answer yet.
I want this project to be easily testable, and I am trying to adhere to TDD methodologies as best I can. I intend to use MSTest and Rhino Mocks for testing.
I was thinking of something like the following for my architecture:
I'd use LINQ-To-SQL to talk to the database. WCF services to define data contract interfaces for the business logic layer. Then use MVP with ASP.NET Forms for the UI/BLL.
Now, this isn't the start of this project, most of the LINQ stuff is already done, so it's stuck. The WCF service would replace the existing DataAccessLayer assembly and the UI/BLL would replace the BusinessLogicLayer assembly etc.
This sort of makes sense in my head, but its getting really late. Anyone that's traveled down this path have any guidance? Good links? Warnings?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
哎呀。获取并阅读 Scott Ambler 的“构建有效的对象应用程序”。你的方法没有并且是一个维护噩梦 - 没有对象。
是的。人为地使应用程序变得比实际情况更复杂、更慢的好方法。扔掉完整的 WCF 服务 - 它们有什么用？ WCF 是针对 SOA 的，而 SOA 存在于用户界面中（即，它是一个信任边界和供另一个应用程序使用的用户界面）。除非你有这样的要求……引入额外的缓慢技术并且只会产生开销是愚蠢的。
每日 WTF - 当您使用 LINQ to SQL 时，您的 DAL 程序集到底有什么用？ LINQ to SQL（运行时）是您的 DAL。
你基本上选择了我能想到的所有反模式——维护噩梦，过度设计，里面有大量无用的技术。您将层技术强加到分层架构中。
读一下我提到的书。
Ouch. Get and read Scott Ambler's "Building Object Applications That Work". Your approach does not and is a maintenance enightmare - no objects.
Yes. Great way to make the application artificially more complicated and slower than it has to be. Throw out the complete WCF service - what are they for? WCF is for SOA, and SOA lives in the user interface (i.e. it is a trust boudary and a user interface for another application to use). Unless you have that requirement.... it is stupid tointroduce additional slow technologies that just have overhead.
The Daily WTF - what the heck do you have a DAL assembly for when you use LINQ to SQL? LINQ to SQL (the runtime) is your DAL.
You basically picked every antipattern I can think of - maintenance nightmare, overdesigned with tons of useless technologies in there. You force layer technologies into a tiered architecture.
Read the book I mentioned.
关于 XXXBusinessLogic，它们很快就成为上帝对象。考虑在您的领域中有意义的代表行为的对象，而不是 BusinessLogic“对象”。这些类型的“对象”将结束执行 XXX 的所有工作，是的，它们是维护的噩梦。
About the XXXBusinessLogic, they become God Objects very quickly. Think in objects that make sense in your domain that represent the behavior, not in BusinessLogic "objects". These sort of "objects" will end performing ALL the work for XXX, and yes, they are a maintenance nightmare.