您是否允许Web层直接访问DAL？ [英] Do you allow the Web Tier to access the DAL directly?
问题描述
我感兴趣的是最佳实践，在这里轻轻一点的现实。
在Web应用程序中，您是否允许您的Web层直接访问DAL，还是应该首先通过BLL？
我正在专门讨论没有业务逻辑真正涉及的情况 - 例如简单的查询：以Atwood姓名获取所有客户。有些任何逻辑的场景绝对会通过BLL，所以请致电 moo 。
虽然您可以将此方法封装在BLL对象中，但通常签名将完全相同时，似乎有点无意义作为DLL对象的代码，代码可能像一个班轮一样将查询委托给DLL。
如果您选择前者 - 使用BLL对象 - 你叫什么对象？ （假设他们做的更多只是将一个查询层提供给DLL）。助手？ QueryProviders？
请注意。
注意
Marty
在我看来，您应该始终使用BLL（业务逻辑层）在您的Web层和您的DAL之间（数据访问层）。
我欣赏一些更简单的查询， BLL将密切模仿DAL（例如，获取所有国家/地区，获取所有产品类型等），但诚实地说，即使在您的示例中：
（获取姓名为
'Atwood'的所有客户）
在此表示业务逻辑数据记录的欲望是通过姓氏过滤的，如果没有其他的话！
通过从项目开始实施BLL，beco mes非常容易插入验证或额外的逻辑，当需要时可能会出现（如果您的项目是商业应用程序，那么最终如果不存在这种需求，几乎会出现项目的开始）。添加额外的逻辑，例如：
获取今年花费
超过$ 10000的所有客户
或
不允许名为Atwood
的客户购买超过$ 1000的商品
当涉及真正的BLL时，变得更容易，而不是试图将这个逻辑撬开到Web层。
$ b请注意，通过上述各种查询，我们几乎肯定会谈到要实现此功能的多个实体和数据库表，它们必须与特定定义的关系联合在一起。尝试通过直接操作DAL来实现这一点变得凌乱，因为你将处理多个实体和类。这里的BLL将大大简化您的网络层代码，因为BLL将封装那些实体关系背后大大简化的界面。
这个分离关注越来越重要，何时需要改变用户界面。
现在至少有两个不同的场合，我已经在商业网页应用程序中使用网站用户界面，并且最终被要求（由于客户在其软件产品中进行更大的集成而产生的业务需求），以生成 web service 界面提供与网站完全相同的功能。
如果我嵌入了任何业务逻辑在我的网络层，我会的在实现我的Web服务时不得不重复和重写这个逻辑。就这样，我确保所有的业务逻辑都封装在BLL类中，这意味着我只需要设计一系列Web服务接口方法调用，并将其插入到BLL类上的方法调用（我实际上使用了 Facade Design Pattern ，以简化Web服务API）。
总而言之，我可以想到没有理由不在我的DAL和我的网络层之间添加BLL层。
最简单的是，当BLL密切地模仿DAL时，是的，似乎有一个重复的代码和功能，然而，同时打字更多，这也使得它相对容易实现。 / p>
当更多的涉及（例如从一开始就存在重要的业务逻辑时），关注点的分离有助于减少重复（ DRY 原则），同时大大简化了未来和持续的维护。
当然，这假设你'重新做所有这些手。如果您愿意，您可以通过使用 ORM 来显着简化DAL / BLL / UI图层一个>其中有很多！
（即 LINQ to SQL / Entities ， SubSonic ， NHibernate 等）
I'm interested in perceived "best practice", tempered with a little dose of reality here.
In a web application, do you allow your web tier to directly access the DAL, or should it go through a BLL first?
I'm talking specifically of scenarios where there's no "business logic" really involved -- such as a simple query : "Fetch all customers with surname of 'Atwood'". Scenarios where there's any kind of logic absolutely are gonna go through the BLL, so lets call that moo.
While you could encapsulate this method inside a BLL object, it seems to be somewhat pointless when often the signature will be exactly the same as that of the DLL object, and the code probably as simple as a one liner delegating the query off to the DLL.
If you choose the former -- employing a BLL object -- what do you call these objects? (Assuming they do little more than provide a query layer into the DLL). Helpers? QueryProviders?
Thoughts please.
Regards
Marty
In my opinion, you should ALWAYS use a BLL (Business Logic Layer) between your web tier and your DAL (Data Access Layer).
I appreciate that for some of the more "simple" queries, the BLL will closely mimic the DAL (e.g. Fetch all countries, Fetch all Product Types etc.), but to honest, even in your example:
(Fetch all customers with surname of 'Atwood')
there is "business logic" being expressed here - A desire for the data records to be filtered by surname, if nothing else!
By implementing a BLL from the start of a project it becomes incredibly easy to insert either validation or additional "logic" as and when the need may arise (and if your project is a commercial application, that need will almost certainly arise eventually if it isn't there at the beginning of the project). Adding in additional logic such as:
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
becomes significantly easier when a true BLL is involved, rather than trying to crowbar this logic into the web tier.
Bear in mind that with the kinds of queries above, we're almost certainly talking about multiple entities and database tables that will have to join together with specifically defined relationships in order to implement this functionality. Trying to achieve this by directly manipulating the DAL becomes messy since you'll be dealing with multiple entities and classes. A BLL here would greatly simplify your web tier code, since the BLL will encapsulate those entity relationships behind a greatly simplified interface.
This "separation of concerns" becomes increasing important when and if the need to change the user interface arises.
On at least two separate occasions now, I've worked on commercial web applications with a web site user interface, and have been eventually asked (due to business need arising from clients seeking greater integration within their software products) to produce a web service interface offering the exact same functionality as the web site.
Had I embedded any business logic within my web tier, I would have had to duplicate and re-write that logic when implementing my web service. As it was, I ensured that all business logic was encapsulated within BLL classes, which meant that I simply had to design a series of web service interface method calls, and plug these up against calls to methods on the BLL classes (I actually used the Facade Design Pattern in places to simplify the web service API).
In all, I can think of no reason to NOT include a BLL layer between my DAL and my web tier.
At it's easiest, when the BLL closely "mimics" the DAL, yes, there does appear to be a duplication of code and functionality, however, whilst being a little more typing, this also makes it relatively easy to implement.
When it's more involved (such as when significant business logic exists from the very beginning), the separation of concerns helps to reduce repetition (the DRY principle) whilst at the same time significantly simplifying future and ongoing maintenance.
Of course, this assumes you're doing all this "by hand". If you so desire, you can significantly simplify the DAL/BLL/UI layers by utilizing an ORM of which there are many! (i.e. LINQ-to-SQL/Entities, SubSonic, NHibernate etc.)
这篇关于您是否允许Web层直接访问DAL？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
