业务层逻辑（BLL）是关于数据的？
我认为 BLL 是关于数据的。它不应包含名为 SendEmail 的方法。 BLL 是一个缓存数据、操作数据、进行与业务相关的计算的地方。发送电子邮件是一个业务流程，但实际发送电子邮件的代码应该位于 BLL 命名空间之外。
BLL 只与数据有关吗？
I think BLL is about Data. It should not include a method called SendEmail. BLL is a place for caching data, manipulating it, doing calculations related to business. Sending email is a business process but the code which actually send the email should be outside of BLL namespace.
Is BLL only about data ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
用户只会与任何应用程序的前端表示形式交互，这通常称为表示层。
数据将作为来自各种数据源的输入/输出显示或交换到该层。这些来源是数据库或网络服务。实际获取这些数据或将这些数据发送到各个数据源的代码就是我们所说的DAL - 数据访问层。
在应用程序之间执行特殊操作，我们称之为应用程序要求或用户需求。应用程序的这一战略部分称为BLL，它实际上满足您正在为其开发应用程序的客户的需求。
如果数据需要存储在数据库中，BLL会有DAL作为底层。
BLL不知道数据源以及如何获取数据或将数据发送到数据源。你有 DAL 来做到这一点。 BLL 只了解数据，更常见的是以业务对象的形式以及对
数据业务对象的操作。BLL 还不知道用户正在使用网站还是桌面应用程序。您有表示层。
User will only interact with the front-end presentation-forms of any application, which is popularly known as presentation layer.
Data will be displayed or exchanged as input/output to this layer from various sources of data. These sources are databases or web-services. The piece of code that actually fetches or sends these data to respective sources of data is what we call as DAL - data access layer.
In between the application does special operations which we call application-requirements or user-needs. This strategic part of the application is called BLL that actually addresses needs of the client for which you are developing the application.
If data needs to be stored in the database, BLL will have DAL as an underlying layer.
BLL is not aware of the sources of data and how data is fetched or sent to data-sources. You have DAL for that. BLL only knows about data, that to in forms of business-objects more often and operations on the
databusiness-objects.BLL also does not know whether user is using website or a desktop application. You have presentation layer for that.
BLL 代表您的业务逻辑层。它应该处理与业务逻辑层相关的任何内容。 SendEmail 在某种实用程序类中可能更好？
另外，如果你告诉 BLL 有关电子邮件机制的信息，你就会给它太多信息（紧密耦合，遵循函数的 demeter 定律，wiki / google）。您的 BLL 不关心也不应该关心电子邮件。
当您提到数据时，您可能会想到DAL（数据访问层）。这是处理数据插入/更新等回某些资源（例如数据库）的层。
BLL stands for your business logic layer. It should handle anything related to your business logic layer. SendEmail may be better in some sort of utility class?
Also if you tell your BLL about an emailing mechanism you are giving it too much information (tightly coupled, follow the law of demeter for functions, wiki / google it). Your BLL doesn't care about email nor should it.
When you mentioned Data, you are probably after the DAL (Data Access Layer). This is the layer that deals with data inserts / updates etc back to some resource such as a database.
BLL 与数据无关……它与业务有关（因此是业务逻辑层）。
DAL 是关于数据的。
我可能会将 SendMail 方法移至 Utility 类，但您需要从 BLL 调用 SendMail 是完全合法的。
BLL isn't about data...it's about Business (hence Business Logic Layer).
The DAL is all about Data.
I'd probably move the SendMail method to a Utility class, but it's perfectly legitimate that you'd need to call SendMail from the BLL.
你的业务逻辑层应该处理与你的业务相关的事情，说你的业务层只与数据有关不太准确。例如，许多人出于性能原因需要缓存数据，因此说缓存是特定于业务的是不正确的。
然而，某些计算（例如计算报价）绝对可以算作业务逻辑，因为它们仅特定于您的业务。
发送电子邮件绝对不是业务逻辑 - 这是一个相当通用的要求，当然不是特定于您的业务或行业的。
Your business logic layer should handle things relating to your business, to say that your business layer is only about data would not quite be accurate. For example many people have the requirement to cache data for performnace reasons, and so to say that caching is business specific would be incorrect.
Certain calculations however (for example calculating a quote) can definitely counted as business logic, as they are specific only to your business.
Sending email is definitely not business logic - this is a fairly generic requirement and certainly isn't specific to your business or industry.
如果从层的角度来看，发送电子邮件更适合表示层，而不是业务逻辑或数据层。
但发送邮件的触发可能来自于业务层，业务层不应该调用表示层。
在这种情况下，潜在的解决方案是让业务层管理电子邮件队列，并让表示层管理接收和发送电子邮件。
有时，严格遵守某种模式可能会导致比它试图解决的问题更多的问题。如果您发现某个特定的实施现在适合您，并且在中短期内不会造成任何问题，并且调查和实施“完美”解决方案的成本太大，那么就使用您现有的解决方案。
If you look at it from a layer perspective, sending emails would fit better into the presentation layer rather than the business logic or data layer.
However, the triggering of sending an email may come from the busines layer, and the business layer should not be calling the presentation layer.
In which case a potential solution would be for the business layer to manage an email queue, and have the presentation layer manage picking up the emails and sending them.
Sometimes conforming rigidly to a pattern can cause more problems than it is trying to solve. If you find a specific implementation works for you now and won't cause any problems in the short to medium term, and the cost of investigating and implementing the "perfect" solution is too great, then go with what you have got.
业务层应该包含保存业务信息的类。该层中的类应该代表您的软件业务。方法应该涉及业务规则。业务层将保存、验证和操作数据，但底层数据访问层 (DAL) 将知道如何从数据库添加、删除、获取和更新数据。业务层也不应该关心表示。
在过去的团队中，我一直致力于开发可以出现在任何程序/业务中的单独功能，例如在其自己的通用类/方法中发送电子邮件。我唯一一次看到 BLL 类与电子邮件有任何联系是在编写业务规则来发送电子邮件时。在本例中，BLL 知道要发送的电子邮件的文本，但实例化了通用电子邮件类来发送电子邮件。
The Business Layer should contain classes that hold business information. Classes in this layer should represent your business in software. Methods should involve business rules. The business layer will hold, validate, and manipulate data, but your underlying Data Access Layer (DAL) will know how to add, remove, get, and update data from the database. The business layer shouldn't care about presentation either.
In the past teams I've always worked on separate functions that can appear in any program/business like sending a email in it's own generic class/method. The only time I've seen a BLL class have any ties to a email is when the business rule was written to send a email. In this case the BLL knew the text of the email to send but instantiated the general email class to send the email.