N层架构设计关注点分离
我意识到已经有很多关于 n 层设计的帖子，这可能是我思考过度和兜圈子，但我自己现在很困惑，希望从社区得到一些澄清。
我试图将我创建的项目（并且一开始在架构上设计得不太好）分成不同的层（每个层都在自己的项目中）：
- UI
- 业务对象
- 逻辑/业务
- DAL
UI 应该只调用逻辑层来获取其内容
业务对象 不应调用或引用任何其他内容，而只是存储数据的一种方式
逻辑 / 业务层应包含系统中获取、创建、更新、删除 (CRUD) 对象的所有方法，并引用 BO 和 DAL。 它将业务逻辑应用于操作，然后将实际的 CRUD 委托给 DAL。
DAL 只会在数据库上执行 CRUD 操作。 它将引用 BO，因为它将返回它们以进行 Get 等。
我的问题是逻辑类是否应该只调用其等效的 DAL 类而只调用逻辑类？ 换句话说，CompanyLogic 类应该只调用CompanyDAL 类。 因此，如果它想通过 ID 获取 Client 对象，它将调用 ClientLogic.GetClientByID(int) 而不是 ClientDAL.GetClientByID(int)。
我认为它可能应该留在自己的层上的原因是：
它似乎会放松项目之间的耦合
逻辑怎么样，如果获取客户端对象中包含一些逻辑验证（可能不是最好的示例，但希望它能理解要点）。
编辑：
我不确定这是否是我的糟糕设计，但目前业务层有许多类，包括 ClientBULL 和 CompnayBULL，这两个类都相互调用。 我为每个类使用一个接口，并有一个工厂来构建对象，以尝试减少任何耦合，但由于调用两个类中的方法，它们现在不能没有彼此而存在。 这是一个坏主意吗？
I realize there have already been a number of posts on n-tier design and this could possibly be me over thinking things and going round in circles, but I have myself all confused now and would like to get some clarity from the community please.
I am trying to separate a project I created, (and didn't design architecturally very well to start with), out into different layers (each in their own project):
- UI
- Business Objects
- Logic / Business
- DAL
The UI should only call the Logic layer to get its stuff
The Business Objects should not call or have references to anything else, just be a way of storing the data
The Logic / BUSINESS layer should hold all of the methods to get, create, update, delete (CRUD) objects in the system and would have references to both the BO and the DAL. It would apply the business logic to the operations then delegate the actual CRUD to the DAL.
The DAL would just do the CRUD operations on the DB. It would have a reference to the BO's as it would return them for the Gets etc.
My question is should the Logic classes only call their equivalent DAL class and just call logic classes instead? In other words, CompanyLogic class should only call CompanyDAL class. So if it wanted to get A Client object by ID it would call ClientLogic.GetClientByID(int) rather than the ClientDAL.GetClientByID(int).
The reason I thought it maybe should stay on the its own layer was that:
It would seem to loosen the coupling between projects
What about the Logic, if getting a client object had some logic validation in it (possibly not the best example, but hope it gets the point across).
EDIT:
I am not sure if it is bad design by me but at the moment the BUSINESS layer has a number of classes including ClientBULL and CompnayBULL, both classes have a call to one another. I use an interface for each class and have a factory to build the objects to try and reduce any coupling but they can not exist without each other now due to calling methods in both classes. Is this a bad idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，这是我对你的设计的评论：
逻辑对于本质上是分配给抽象持久性的层来说是一个坏名字。 我可能会将其称为“存储库”或“持久性”或 DAO（数据访问对象），而不是“逻辑”，这是含糊不清的，并且绝对可能意味着任何东西。
如果您确实想将业务层与 DAL 解耦，则逻辑层应该只接受 DAL 的接口，而不接受具体的 DAL 类。
如果
关于验证应该在哪里存在两个流派。 有些完全可以在 UI 层进行验证；有些则完全可以接受。 其他人宁愿抛出异常或从业务层传递消息。 无论采用哪种方式，只要保持一致，不要在多个地方重复验证，就可以了。
继续尝试编码可能是我能给您的最好建议。 仔细思考一下是很好的，但在某一时刻，您需要在编码时看到它，只有这样，微妙的怪癖和陷阱才会显现出来。 无论您能提出什么原型，都绝对对您的开发和设计方向有价值。
祝你好运！
更新
重新编辑：在同一命名空间或程序集中，调用具体类绝对没问题。 我认为您需要为业务逻辑建立接口会过于复杂——我的意思是您应该遵循一组以上的规则吗？
我坚信让事情变得简单并遵循 YAGNI。 在有两个以上的类将要实现/已经实现该接口之前，不要创建接口（但 DAL 始终是一个例外）。
Well, here's my comments on your design:
Logic is a bad name for what essentially is a layer assigned to abstract persistence. I would probably call it "Repository" or "Persistence" or DAO (data access objects) instead of "Logic", which is ambiguous and could absolutely mean anything.
If you really want to decouple your business layer from your DAL, your Logic layer should only accept interfaces to the DAL, and not concrete DAL classes.
There are two schools of thought as to where validation should reside. Some are completely fine with validation sitting at the UI layer; others would rather throw exceptions or pass messages from the business layer. Whichever way you go, just be consistent, don't duplicate validations in multiple places, and you'll be fine.
Go ahead and try coding it would probably be the best piece of advice I could give you. It's well and fine thinking it through, but at one point you'll need to see it while you're coding it and only then will subtle quirks and pitfalls reveal themselves. Whatever prototypes you can come up with will definitely be valuable to the direction your development and design takes you.
Goodluck!
Update
Re your edit: Within the same namespace or assembly, calls to concrete classes are definitely fine. I think it will be overly convoluted for you to need to put up interfaces for business logic -- I mean is there more than one set of rules you should follow?
I'm a believer of keeping things simple and following YAGNI. Don't make an interface until there are more than two classes that are going to implement/already implementing that interface (the DAL is always an exception to this though).