我认为 BLL 是关于数据的。它不应包含名为 SendEmail 的方法。 BLL 是用于缓存数据、操作数据、进行与业务相关的计算的地方。发送电子邮件是一个业务流程，但实际发送电子邮件的代码应该在 BLL 命名空间之外。
BLL 仅与数据有关吗？
【问题讨论】：
标签： architecture business-logic
BLL 不是关于数据，而是关于需要用 数据。
用户只会与任何应用程序的前端表示形式交互，这通常称为表示层。
数据将从各种数据源显示或交换为该层的输入/输出。这些来源是数据库或网络服务。实际获取这些数据或将这些数据发送到相应数据源的代码就是我们所说的DAL - 数据访问层。
在应用程序之间执行我们称为 application-requirements 或 user-needs 的特殊操作。应用程序的这一战略部分称为 BLL，它实际上满足了您正在为其开发应用程序的客户的需求。
如果需要将数据存储在数据库中，BLL 将以 DAL 作为底层。
BLL不了解数据的来源以及数据如何获取或发送到数据源。你有 DAL。 BLL 只知道数据，更频繁地以业务对象的形式以及对 data business-objects 的操作。
BLL 也不知道用户使用的是网站还是桌面应用程序。你有表示层。
【讨论】：
BLL 代表您的业务逻辑层。它应该处理与您的业务逻辑层相关的任何事情。 SendEmail 在某种实用程序类中可能会更好？
另外，如果你告诉你的 BLL 一个电子邮件机制，你给了它太多的信息（紧密耦合，遵循函数的 demeter 定律，wiki / google it）。您的 BLL 不关心电子邮件也不应该关心。
当您提到数据时，您可能是在 DAL（数据访问层）之后。这是处理数据插入/更新等回到某些资源（如数据库）的层。
【讨论】：
BLL 与数据无关……它与业务有关（因此是 业务 逻辑层）。
DAL 是关于数据的。
我可能会将 SendMail 方法移至 Utility 类，但您需要从 BLL 调用 SendMail 是完全合法的。
【讨论】：
您的业务逻辑层应该处理与您的业务相关的事情，如果说您的业务层仅与数据有关，那是不太准确的。例如，许多人出于性能原因需要缓存数据，因此说缓存是特定于业务的是不正确的。
但是，某些计算（例如计算报价）绝对可以算作业务逻辑，因为它们只针对您的业务。
发送电子邮件绝对不是业务逻辑 - 这是一个相当通用的要求，当然不是特定于您的业务或行业。
【讨论】：
如果您从层的角度来看，发送电子邮件更适合表示层而不是业务逻辑或数据层。
但是，发送邮件的触发可能来自业务层，业务层不应该调用表现层。
在这种情况下，一个潜在的解决方案是让业务层管理电子邮件队列，并让表示层管理接收电子邮件并发送它们。
有时，严格遵循某种模式可能会导致比它试图解决的问题更多的问题。如果您发现某个具体的实施现在适合您，并且在中短期内不会造成任何问题，并且调查和实施“完美”解决方案的成本太高，那么就按照您所拥有的去做吧。
【讨论】：
业务层应包含保存业务信息的类。这一层中的类应该代表您在软件中的业务。方法应该涉及业务规则。业务层将保存、验证和操作数据，但您的底层数据访问层 (DAL) 将知道如何从数据库中添加、删除、获取和更新数据。业务层也不应该关心表示。
在过去的团队中，我一直致力于开发可以出现在任何程序/业务中的单独功能，例如在它自己的通用类/方法中发送电子邮件。我唯一一次看到 BLL 类与电子邮件有任何联系是在编写业务规则以发送电子邮件时。在这种情况下，BLL 知道要发送的电子邮件的文本，但会实例化通用电子邮件类来发送电子邮件。
【讨论】：