我对“最佳实践”感兴趣，在这里用一点点的现实来缓和。
在Web应用程序中，您是否允许您的Web层直接访问DAL，或者它是否应首先通过BLL？
我特别谈的是没有真正涉及“业务逻辑”的场景 - 例如简单的查询：“获取姓氏为'Atwood'的所有客户”。绝对有任何逻辑的场景都会通过BLL，所以我们称之为moo。
虽然可以将此方法封装在BLL对象中，但是当签名与DLL对象的签名完全相同时，似乎有点无意义，代码可能就像一个内核将查询委托给DLL。
如果选择前者 - 使用BLL对象 - 你称这些对象是什么？ （假设它们只是在DLL中提供查询层）。助手？ QueryProviders？
请注意。
此致
玛蒂
答案 0 :(得分：34)
我不同意这里的大多数帖子。
我在Web层中调用我的数据层。如果WEB / UI层之间没有任何内容，则无需创建“以防万一”的层。这是预优化。这是浪费。我记不起业务层“救了我”的时间。它所做的只是创造了更多的工作，重复和更高的维护。我花了数年时间订阅业务层 - ＆gt;数据层在层之间传递实体。我总觉得很难创造通过没有做任何事情的方法。
在介绍Domain Driven Design by Eric Evans之后，我做了有意义的事情。如果UI和数据层之间没有任何内容，那么我在UI中调用数据层。
为了允许将来的更改，我将所有数据层类包装在接口中。在UI中，我引用了接口，并使用依赖注入来管理实现。在做出这些改变后，它就像一股清新的空气。如果我需要在数据层和UI之间注入一些内容，我就会创建一个服务。
我做的另一件事是减少项目数量。在我有一个数据层，业务逻辑，业务实体和某种类型的UI项目的项目之前 - 真是太痛苦了。
我有两个项目：核心项目（实体，业务逻辑和数据层）和UI项目（Web，Web服务等......）
有关更多信息，我建议您查看这些人：
答案 1 :(得分：5)
在我看来，您应该始终在您的网络层和您的DAL（Business Logic Layer）之间使用BLL（Data Access Layer）。
我很欣赏对于一些更“简单”的查询，BLL会非常模仿DAL（例如，获取所有国家/地区，获取所有产品类型等），但诚实，即使在您的示例中：
（取所有姓氏的客户 '阿特伍德'）
这里表达了“业务逻辑” - 希望通过姓氏过滤数据记录，如果没有别的话！
通过从项目开始实施BLL，在需要时可以非常容易地插入验证或其他“逻辑”（如果您的项目是商业应用程序，则需要几乎如果在项目开始时不存在，最终会出现。添加其他逻辑，例如：
当涉及真正的BLL时，获取所有已消费的客户 今年超过10000美元
或
不允许姓氏为“Atwood”的客户 购买超过1000美元的物品
变得非常容易，而不是试图将这种逻辑扼杀到Web层。
请记住，通过上述各种查询，我们几乎肯定会讨论多个实体和数据库表，这些表必须与特定定义的关系连接在一起才能实现此功能。试图通过直接操作DAL实现这一点变得混乱，因为你将处理多个实体和类。这里的BLL将大大简化您的Web层代码，因为BLL将encapsulate大大简化的界面背后的那些实体关系。
当需要更改用户界面时，此“separation of concerns”变得越来越重要。
至少在两个不同的场合，我曾经使用网站用户界面开展商业网络应用程序，最终被要求（由于客户寻求在其软件产品中寻求更好集成的业务需求）来生产web service界面提供与网站完全相同的功能。
如果我在我的Web层中嵌入了任何业务逻辑，那么在实现我的Web服务时，我将不得不复制并重写该逻辑。事实上，我确保所有业务逻辑都封装在BLL类中，这意味着我只需设计一系列Web服务接口方法调用，并将这些调用插入BLL类上的方法调用（我实际上使用了Facade Design Pattern用于简化Web服务API的地方。）
总之，我认为 NOT 没有理由在我的DAL和我的网络层之间包含BLL图层。
最简单的是，当BLL紧密“模仿”DAL时，是的，似乎确实存在重复的代码和功能，但是，在进行更多打字时，这也使得它相对容易实现。 / p>
当它涉及更多时（例如从一开始就存在重要的业务逻辑），关注点的分离有助于减少重复（DRY原则），同时显着简化未来和持续的维护。
当然，这假设你“手动”做这一切。如果您愿意，可以使用ORM来大大简化DAL / BLL / UI层，其中有很多！ （即LINQ-to-SQL/Entities，SubSonic，NHibernate等）
答案 2 :(得分：2)
你需要区分BLL对象（无论如何这些对象？域对象是谁？）和服务。您的域对象应该与您的数据访问层无关。就Web层而言，它可以像处理它可以自由使用的任何其他服务一样对待您的存储库（想象IRepository）。
所以底线是：是的，Web层可以直接使用DAL，前提是它是属性封装的，并表示为标准的服务层服务。
答案 3 :(得分：1)
即使它处于打开状态;在BLL中对DLL进行类似调用的一行中，抽象允许您在该层中添加业务逻辑，而不必影响任何其他层。它现在可能看起来不太可能，但是在您发生变更之后，无论谁支持应用程序都会感谢您使用这样的模式。
至于命名，我有我的核心对象，比如一个NameChange，然后我将有一个BLL对象是一个接受名称更改对象的人，然后我将有一个名为Person的DAL / Entity对象。业务Person对象位于BLL命名空间内，DAL / Entity Person对象位于DB命名空间中（如果我最初构建它，我会选择DAL。）
答案 4 :(得分：1)
我们将此层称为Controller类[layer]，它从Web层封装DAL。控制器层可能有也可能没有任何业务逻辑，它确实有助于将DAL与表示层隔离并使它们在某种程度上保持独立。
答案 5 :(得分：0)
我们倾向于使用facade pattern进行访问，虽然我们使用它的项目规模很大，但我认为它可能会对较小的项目造成过度杀伤。
本质：
用户界面 - ＆gt; BusFacade - ＆gt; BusinessLogic - ＆gt; DalFacade - ＆gt; DataAccessLayer
Facade从UI中获得了一个漂亮/干净的方法，并强制您标准化您的命名约定，因为单个入口点有许多方法。
BusFacade.GetCmsSiteMap()
BusFacade.GetProductGroup()
etc.etc。
答案 6 :(得分：0)
虽然可以直接从Presentation层转到DAL，但你正在跳过通常需要身份验证的BLL ......