在Web应用程序中，您是否允许您的Web层直接访问DAL，还是应该先通过BLL？
我正在专门谈论没有“业务逻辑”真正涉及的情况 – 例如一个简单的查询：“获取姓氏为”Atwood“的所有客户。那里有任何一种逻辑的场景绝对会通过BLL，所以让我们称之为moo。
虽然您可以将此方法封装在BLL对象中，但通常签名与DLL对象的签名完全相同时，似乎有点无意义，而且代码可能与将一个委托委托给DLL的一个线程一样简单。
如果您选择前者 – 使用BLL对象 – 您称之为这些对象？ (假设他们做的更多只是将一个查询层提供给DLL)。助手？ QueryProviders？
想想
问候
马蒂
解决方法
我明白，对于一些更“简单”的查询，BLL将会非常模拟DAL(例如，获取所有国家/地区，获取所有产品类型等)，但诚实地说，即使在您的示例中：
(Fetch all customers with surname of
‘Atwood’)
在这里表达了“业务逻辑” – 如果没有别的话，数据记录的需求被过滤掉，
通过从项目开始实施BLL，变得非常容易插入验证或额外的“逻辑”，当需要时可能会出现(如果您的项目是商业应用程序，那么这个需求几乎肯定会最终产生，如果它是在项目开始的时候)。添加额外的逻辑，如：
Fetch all customers who have spent
over $10000 this yearor
Don’t allow customers with the surname of ‘Atwood’
to purchase items over $1000
当涉及真正的BLL时，变得更容易，而不是试图将这个逻辑撬开到Web层。
请记住，通过上述各种查询，我们几乎肯定会谈到要实现此功能的多个实体和数据库表，它们必须与特定定义的关系联合在一起。尝试通过直接操作DAL来实现这一点变得凌乱，因为你将处理多个实体和类。这里的BLL将大大简化您的Web层代码，因为BLL将encapsulate这些实体关系放在大大简化的界面之后。
当“separation of concerns”变得越来越重要，如果需要改变用户界面。
至少在两个不同的场合，我已经在商业网页应用程序上使用网站用户界面，并且最终被要求(由于客户在其软件产品中获得更大的集成而产生的业务需求)，以生产一个web service接口产品与网站完全相同的功能。
如果我在我的网络层中嵌入了任何业务逻辑，那么在实现我的Web服务时，我不得不重复和重写这个逻辑。就这样，我确保所有的业务逻辑都封装在BLL类中，这意味着我只需要设计一系列Web服务接口方法调用，并将其插入到BLL类上的方法调用(我实际上使用了Facade Design Pattern在地方简化Web服务API)。
总而言之，我可以想到没有理由不在我的DAL和我的Web层之间加入BLL层。
最简单的是，当BLL密切地“模仿”DAL时，是的，似乎有一个重复的代码和功能，然而，尽管多一点打字，这也使得它相对容易实现。
当它更多地涉及(例如从一开始就存在重要的业务逻辑时)，关注的分离有助于减少重复(DRY原则)，同时显着简化未来和持续的维护。
当然，这假设你正在做这些“手工”。如果您愿意，您可以通过使用其中有很多的ORM来显着简化DAL / BLL / UI层。
(即LINQ-to-SQL/Entities，SubSonic，NHibernate等)
