我启动了我的网站，就像stackoverflow一样，有一点技术债务，我正试图还清。作为合约开发人员，我去过很多地方并且看到了很多不同的方法来实现这个结果，但我的方式是......
演示文稿（网页）
业务层（旧式实体类和BL层）
数据层（通过存储过程到SQL Server的DA类）
我的问题主要涉及业务层。现在我有一个Entity命名空间和一个BusinessLogic命名空间。
BL具有对DA和实体的引用。 实体提到了DA （DA“不知道”BL或实体）
我真的希望将数据转化为实体的所有内容都发生在BL中 - 因此也就是业务逻辑。但是，我希望实体能够在需要时访问BL - 从而删除实体对DL的引用。
因此...
将BL和Entity对象放在同一名称空间中以便它们可以一起工作是“错误的”吗？
基本上，我正在尝试像Employee这样的实体对象（经典示例，嗯？）并让Employee有一个
public Hashtable[] SubordinateEmployees
属性，返回向该员工报告的其他Employee对象的Hashtable。但我不想在需要之前加载它。因此，对于大多数员工来说，财产永远不会被访问，但是当它发生时，它会通过调用BL来自动加载，BL调用DA。
这个问题有意义吗？
如果是的话，我的解决方案是什么？
提前非常感谢！
答案 0 :(得分：2)
处理你的例子所代表的那种情况的通常方法是外立面。您不必尝试从Employee对象中获取下级员工，而是使用对业务逻辑的调用来获取它。
hashtable = BL.GetSubordinateEmployees(supervisor);
通过这种方式，您可以单点访问下属，并且只有一件事（BL）访问数据层并创建实体。
答案 1 :(得分：2)
让我看看我是否可以告诉你更好的方式来考虑这个
你有你的数据访问权限（sql server，mysql，flat xml文件等）所有这一切应该被抽象掉你的应用程序应该关心或知道你如何获取你的数据，只有它是剂量，如果其他任何事情都知道你如何获得你的数据，你有一个图层违规。如果DAL给其他任何东西加药，那么获取数据就会导致图层违规。接下来，您将实现一个类似于业务层使用的IDAL的数据访问接口，这对于通过强制您分离图层来使代码可测试非常重要。
您的数据实体可以放置在DAL名称空间中，也可以将它们分配给自己，让它们有自己的力量分离。数据实体是愚蠢的对象，应该包含很少甚至没有逻辑，只知道自己和他们拥有的数据，他们不包含商业逻辑！，数据访问LOCIC或UI逻辑。如果他们你有一个图层违规。数据实体的唯一功能是保存数据并从一层传递到下一层。
Biz层实现了一个数据访问接口，就像我们谈到的IDAL，然后你可以用工厂，IOC容器或其他所有失败的具体类型来实例化它，但添加一个setter属性，这样就可以改变它来进行测试。 Biz Layer Only只处理业务逻辑，它不知道或关心数据的来源或去向，它只关心操纵数据以符合业务规则，这包括日期验证，过滤（部分内容是告诉DAL它需要什么数据，让DAL弄清楚如何获得它。基本上，BIZ处理与UI无关或与数据检索相关的所有逻辑。就像DAL一样，Biz也应该出于同样的原因实现接口。
UI层以与出于同样原因的Biz层访问DAL相同的方式访问Biz层。所有UI层关心的是显示数据并从用户获取数据。 IU层不应该对业务规则有任何了解，可能的例外是填充数据实体所需的数据验证。
这种架构的优势在于它强制分离关注点，使其更容易测试，更灵活，更易于维护。今天你正在建立一个网站，但明天你想让其他人整合一个网络服务，所有你要做的就是创建一个实现IBIZ界面的网络服务和你完成的工作，当你必须修复BIZ中的一个bug时图层，它已经在您的网站和Web服务中修复。
将这个提升到一个新的水平，让我们说你正在进行大量繁重的数据处理，你需要更强大的服务器来处理这个问题，所以你所要做的就是实现一个IDal和IBIZ接口，这些接口实际上是WCF的包装器处理服务器之间的通信，现在您的应用程序分布在多个服务器之间，您无需更改代码即可。