我启动了我的网站，就像stackoverflow一样，当时我要偿还一些技术债务。作为合同开发人员，我去过很多地方，看到了许多实现此结果的方法，但是我要走的路是。
演示文稿（网络）
业务层（老式实体类和BL层）
数据层（通过存储的Pro到SQL Server的DA类）
我的问题主要涉及业务层。现在，我有一个Entity命名空间和一个BusinessLogic命名空间。
BL引用了DA和实体。
实体参考了发展议程
（DA不了解BL或实体）
我真的很希望在BL内进行将数据转换为实体的所有工作，从而实现业务逻辑。但是，我希望该实体能够在需要时访问BL，从而删除该实体对DL的引用。
所以...
将BL和Entity对象放在同一个命名空间中以便它们可以一起工作是“错误的”吗？
本质上，我正在尝试拥有一个像Employee这样的实体对象（经典示例，是吗？），并且让Employee具有一个
public Hashtable[] SubordinateEmployees
属性，该属性返回向此员工报告的其他Employee对象的Hashtable。但是我不想在需要之前加载它。因此，对于大多数员工来说，永远不会访问该属性，但是当它访问时，它会通过调用BL（称为DA）的调用自动加载。
这个问题有意义吗？
如果是这样，我的解决方案吗？
非常感谢！
最佳答案
处理示例所代表的那种情况的通常方法是使用立面。与其尝试从Employee对象中获取下属雇员，不如使用对业务逻辑的调用来获取它。
hashtable = BL.GetSubordinateEmployees(supervisor);
这样，您可以对下属进行单点访问，并且只有一件事（BL）可以访问数据层并创建实体。
关于c# - 需要n层架构反馈，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/607683/