design-patterns - 您是否允许 Web 层直接访问 DAL？

Question

我对感知到的“最佳实践”感兴趣，这里有一点现实。

在 Web 应用程序中，您是允许您的 Web 层直接访问 DAL，还是应该先通过 BLL？

我说的是没有真正涉及“业务逻辑”的场景——例如一个简单的查询:“获取所有姓氏为'Atwood'的客户”。有任何逻辑的场景绝对会通过 BLL，所以我们称之为 moo .

虽然您可以将此方法封装在 BLL 对象中，但如果签名通常与 DLL 对象的签名完全相同，并且代码可能像将查询委托(delegate)给 DLL 的单行代码一样简单，这似乎有点毫无意义.

如果你选择前者——使用 BLL 对象——你怎么称呼这些对象？ (假设他们只是在 DLL 中提供一个查询层)。 helper ？查询提供者？

请思想。

问候

马蒂

Answer 1

我不同意这里的大多数帖子。

我在 Web 层中调用我的数据层。如果 WEB/UI 层之间没有任何内容，那么创建一个“以防万一”层是没有意义的。是预优化。这是一种浪费。我不记得业务层“拯救了我”的时间。它所做的只是创造了更多的工作、重复和更高的维护。我花了数年时间订阅业务层 --> 数据层在层之间传递实体。我总是觉得通过什么都不做的方法创建传递是肮脏的。

被介绍到Domain Driven Design by Eric Evans后，我做有意义的事。如果 UI 和数据层之间没有任何内容，那么我在 UI 中调用数据层。

为了允许将来进行更改，我将所有数据层类包装在接口(interface)中。在 UI 中，我引用接口(interface)并使用依赖注入(inject)来管理实现。做出这些改变之后，就像呼吸到了一股新鲜空气。如果我需要在数据层和 UI 之间注入(inject)一些东西，我会创建一个服务。

我做的另一件事是减少项目的数量。在我有一个数据层、业务逻辑、业务实体和某种类型的 UI 项目的项目之前——真是太痛苦了。

我有两个项目:核心项目(实体、业务逻辑和数据层)和 UI 项目(Web、Web 服务等...)

有关更多信息，我建议查看这些人:

Develop with Passion

Jeffrey Palermo

David Laribee