我认为BLL是关于数据的。它不应该包含一个名为SendEmail的方法。 BLL是一个缓存数据,操纵数据,进行与业务相关的计算的地方。发送电子邮件是一个业务流程,但实际发送电子邮件的代码应该在BLL名称空间之外。
BLL只关于数据吗?
答案 0 :(得分:12)
BLL不是关于数据,而是关于需要做什么的 数据强>
用户只会与任何应用程序的前端演示文稿进行交互,这种形式通常称为表示层。
数据将从各种数据来源显示或交换为此图层的输入/输出。这些来源是数据库或网络服务。实际上将这些数据提取或发送到各个数据源的代码片段就是我们所说的 DAL - 数据访问层。
在应用程序之间执行特殊操作,我们称之为应用程序要求或用户需求。该应用程序的战略部分称为 BLL ,实际上解决了您正在为其开发应用程序的客户端的需求。
如果数据需要存储在数据库中, BLL将DAL作为基础层。
BLL 不知道数据来源以及如何将数据提取或发送到数据源。你有DAL。 BLL只知道数据,更多地以业务对象的形式知道数据,以及数据 业务对象上的操作。
BLL 也不知道用户是使用网站还是桌面应用。你有表示层。
答案 1 :(得分:3)
BLL代表您的业务逻辑层。它应该处理与业务逻辑层相关的任何事情。 SendEmail在某种实用程序类中可能更好吗?
另外,如果你告诉你的BLL关于电子邮件机制你给它太多的信息(紧密耦合,遵循demeter法则的功能,维基/谷歌它)。你的BLL不关心电子邮件也不应该关心。
当您提到数据时,您可能正在使用DAL(数据访问层)。这是将数据插入/更新等处理回某些资源(如数据库)的层。
答案 2 :(得分:2)
BLL与数据无关......它与业务有关(因此业务逻辑层)。
DAL就是数据。
我可能会将SendMail方法移动到Utility类,但是你需要从BLL调用SendMail是完全合法的。
答案 3 :(得分:0)
您的业务逻辑层应该处理与您的业务相关的事情,并说您的业务层只是关于数据不太准确。例如,许多人都需要为执行原因缓存数据,因此说缓存是特定于业务的是不正确的。
然而,某些计算(例如计算报价)绝对可以算作业务逻辑,因为它们仅针对您的业务。
发送电子邮件绝对不是商业逻辑 - 这是一个相当普遍的要求,当然不是针对您的业务或行业。
答案 4 :(得分:0)
如果从图层角度来看,发送电子邮件会更好地适应表示层而不是业务逻辑或数据层。
但是,发送电子邮件的触发可能来自商务层,而业务层不应该调用表示层。
在这种情况下,可能的解决方案是业务层管理电子邮件队列,并让表示层管理接收电子邮件并发送它们。
有时严格遵守模式可能会导致比尝试解决更多的问题。如果您发现某个特定的实现现在适合您,并且在短期到中期内不会造成任何问题,并且调查和实施“完美”解决方案的成本太高,那么请继续使用您所拥有的。
答案 5 :(得分:0)
业务层应包含保存业务信息的类。此层中的类应代表您在软件中的业务。方法应涉及业务规则。业务层将保存,验证和操作数据,但您的基础数据访问层(DAL)将知道如何添加,删除,获取和更新数据库中的数据。业务层也不应该关心表示。
在过去的团队中,我一直致力于可以出现在任何程序/业务中的单独功能,例如在其自己的通用类/方法中发送电子邮件。我发现BLL课程与电子邮件有任何联系的唯一时间是编写业务规则以发送电子邮件。在这种情况下,BLL知道要发送的电子邮件的文本,但实例化了通用电子邮件类以发送电子邮件。