需要 n 层架构反馈
我开始了我的网站，就像 stackoverflow 一样，带着一些我正在努力偿还的技术债务。 作为一名合约开发人员，我去过很多地方，看到过很多不同的方法来实现这个结果，但我要走的方法是..
表示（Web）
业务层（老式实体类和 BL 层）
数据层（通过存储过程到 SQL Server 的 DA 类）
我的问题主要涉及业务层。 现在我有一个实体命名空间和一个业务逻辑命名空间。
BL 引用了 DA 和实体。 该实体有对 DA 的引用 （DA“不知道”BL 或实体）
我真的希望将数据转变为实体的所有操作都发生在 BL 中——因此是业务逻辑。 但是，我希望实体能够在需要时访问 BL，从而删除实体对 DL 的引用。
那么...
将 BL 和实体对象放在同一名称空间中以便它们可以一起工作是“错误的”吗？
本质上，我正在尝试拥有一个像 Employee 这样的实体对象（经典示例，呃？），并让 Employee 有一个
public Hashtable[] SubordinateEmployees
属性，该属性返回向该员工报告的其他 Employee 对象的哈希表。 但我不想在需要时加载它。 因此，对于大多数员工来说，该属性永远不会被访问，但当访问时，它会通过调用 BL 来自动加载，而 BL 又调用 DA。
这个问题有意义吗？
如果是这样，我的解决方案可以吗？
非常感谢！
I started my website, like stackoverflow, with a little technical debt that I'm trying to pay off. Being a contract developer, I've been in many places and see many different methods of achieving this result, but the way I'm going is..
Presentation (web)
Business Layer (old fashioned entity classes and BL layer)
Data Layer (DA classes to SQL Server via Stored Proc)
My question primarily concerns the Business Layer. Right now I have an Entity namespace and a BusinessLogic namespace.
The BL has a reference to the DA and the Entity.
The Entity has a reference to the DA
(The DA is "unaware" of the BL or Entity)
I really want all my churning of turning Data into Entities to occur within the BL -- thus the Business Logic. However, I want the Entity to be able to access the BL if need be -- and thus remove the Entity's reference to the DL.
So...
Is is "wrong" to have the BL and Entity objects within the same namespace so they can work together?
Essentially, I'm trying have an entity object like Employee (classic example, eh?) and have the Employee have a
public Hashtable[] SubordinateEmployees
property that returns a Hashtable of other Employee objects that report to this employee. But I don't want to load it until it's needed. So for most employees the property would never get accessed, but when it does, it self-loads with a call to the BL, which calls the DA.
Does the question make sense?
If so, does my solution?
Thanks so much in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
处理您的示例所代表的情况的通常方法是使用外观。 您无需尝试从 Employee 对象获取下级员工，而是使用对业务逻辑的调用来获取它。
这样，您就可以对下级进行单点访问，并且只有一件事（BL）访问数据层并创建实体。
The usual way to deal with the kind of situation your example represents is with facades. Instead of trying to get the subordinate employees from the Employee object, you use a call to the business logic to get it.
That way you have a single point of access to the subordinates, and there is only one thing (the BL) accessing the data layer and creating Entities.
让我看看我是否可以向您展示一种更好的方式来考虑这个问题，
您可以访问数据（sql server、mysql、平面 xml 文件等），所有这些都应该被抽象出来，您的应用程序中没有其他内容应该关心或知道如何你正在获取你的数据，只是它剂量，如果有其他东西知道你如何获取你的数据，那么你就有了层违规。 如果 DAL 执行任何其他操作，则获取数据，则存在层违规。 接下来，您将实现业务层使用的数据访问接口（例如 IDAL），这对于通过强制分离层来使代码可测试非常重要。
您的数据实体可以放置在 DAL 名称空间中，或者给它们自己的，给它们自己的力量分离。 数据实体是哑对象，应该包含很少甚至不包含逻辑，并且只知道它们自己和它们拥有的数据，它们不包含业务逻辑！、数据访问逻辑或 UI 逻辑。 如果有，则说明存在图层违规。 数据实体的唯一功能是保存数据并将数据从一层传递到下一层。
Biz 层实现了一个数据访问接口，就像我们讨论过的 IDAL 一样，您可以使用工厂、IOC 容器或其他所有无法实现具体类型的实例来实例化它，但添加一个 setter 属性，以便可以更改它以进行测试。 业务层只处理业务逻辑，它不知道也不关心数据从哪里来或去往哪里，它只关心操纵数据以符合业务规则，这包括日期验证、过滤（其中一部分是告诉 DAL 它需要什么数据，让 DAL 弄清楚如何获取它）。 基本上，BIZ 处理与 UI 相关或与数据检索无关的所有逻辑。 就像 DAL 一样，出于同样的原因，企业应该实现一个接口。
UI 层访问 Biz 层的方式与 Biz 层访问 DAL 的方式相同，原因相同。 UI 层关心的只是显示数据和从用户那里获取数据。 IU 层不应该了解任何有关业务规则的信息，填充数据实体所需的数据验证可能除外。
这种架构的优点是它强制关注点分离，使其更容易测试、更灵活、更容易维护。 今天您正在构建一个网站，但明天您希望允许其他人通过 Web 服务集成，您所要做的就是创建一个实现 IBIZ 接口的 Web 服务，当您必须修复 BIZ 中的错误时，您就完成了层，它已经固定在您的网站和网络服务中。
将其提升到一个新的水平，假设您正在进行大量繁重的数字运算，并且需要更强大的服务器来处理此问题，因此您所要做的就是实现 IDal 和 IBIZ 接口，它们实际上是处理通信的 WCF 的包装器在您的服务器之间，现在您的应用程序分布在多个服务器之间，并且您不必更改代码即可完成此操作。
Let me see if I can show you a better way to think about this
you have your data access (sql server, mysql, flat xml files, etc.) all of this should be abstracted away nothing else in your application should care or know how you are getting your data, only that it dose, if anything else knows how you are getting your data you have a layer violation. if the DAL dose anything other then get data you have a layer violation. Next you implement a data access interface something like IDAL that your business layer uses, this is very important for making your code testable by forcing you to separate your layers.
Your data entities can be placed in the DAL name space or give them there own, Giving them there own forces separation. Data entities are dumb objects and should contain very little to no logic and are only aware of themselves and the data they have, THEY DO NOT CONTAIN BUSINESS LOGIC!, DATA ACCESS LOCIC, OR UI LOGIC. if they do you have a layer violation. The only function of a data entity is to hold data and be passed from one layer to the next.
Biz layer implements a data access interface like the IDAL we talked about before you can instantiate this with a factory, an IOC container, or all else failing a concrete type, but add a setter property so this can be changed for testing. The Biz Layer Only handles Business logic, it doesn't know or care where the data came from or where it's going, it only cares about manipulating the data to comply with business rules, this would include date validation, filtering (part of this is telling the DAL what data it needs, let the DAL figure out how to get it). Basically the BIZ handles all logic that isn't UI related or Data retrieval related. Just like the DAL the Biz should implement an Interface for the same reason.
The UI layer Accesses the Biz layer the same way the Biz layer accesses the DAL for the same reason. All the UI layer cares about is displaying data and getting data from the user. The IU Layer should not know anything about the business rules, with the possible exception of data validation required to populate the Data Entities.
The advantage of this architecture is it forces separation of concern making it easier to test, more flexible, and easier to maintain. Today you are building a web site but tomorrow you want to allow others to integrate vi a web service, all you have to do is create a web service that implements the IBIZ interface and your done, when you have to fix a bug in the BIZ layer, it's already fixed in both your website and web service.
Taking this to the next level, lets say you are doing a lot of heavy number crunching and you need more powerful servers to handle this so all you have to do is implement an IDal and IBIZ interface that are really wrappers to WCF that handles the communication between your servers, now your application is distributed between multiple server and you didn't have to change your code to do it.