设计模式 – 您是否允许Web层直接访问DAL？

在我看来，您应该始终使用BLL( Business Logic Layer)在您的网络层和您的DAL( Data Access Layer)之间。

我明白，对于一些更“简单”的查询，BLL将会非常模拟DAL(例如，获取所有国家/地区，获取所有产品类型等)，但诚实地说，即使在您的示例中：

(Fetch all customers with surname of
‘Atwood’)

在这里表达了“业务逻辑” – 如果没有别的话，数据记录的需求被过滤掉，

通过从项目开始实施BLL，变得非常容易插入验证或额外的“逻辑”，当需要时可能会出现(如果您的项目是商业应用程序，那么这个需求几乎肯定会最终产生，如果它是在项目开始的时候)。添加额外的逻辑，如：

Fetch all customers who have spent
over $10000 this year

or

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等)