问题标签 [business-logic-layer]

没有如下 BLL（业务逻辑层）的ASP.Net 2.0应用程序是否“可以接受” ？

1. SQL Server 数据存储和存储过程
2. 连接到存储过程的数据链路层（强类型表适配器）
3. 带有代码的表示层 ASPX 页面和用于直接连接到 DLL 的 ObjectDataSource

即使业务逻辑在演示文稿的代码中完全可验证，BLL 是否总是更可取？不使用 BLL 的潜在缺点是什么？

我无数次听到我们“不应该将业务逻辑与其他代码混合”或类似的语句。我认为我编写的每一个代码（我的意思是处理步骤）都包含与业务需求相关的逻辑。

谁能告诉我业务逻辑到底是什么？它如何与其他代码区分开来？是否有一些简单的测试来确定什么是业务逻辑，什么不是？

我正在使用相当标准的 Web/服务/数据访问分层设计构建一个用于娱乐/学习的小型网站。

为了使我不必经常创建服务层/数据访问层类的实例，我将它们中的方法全部设为静态。我不应该遇到并发问题，因为它们使用局部变量等并且不共享任何资源（目前事情很简单）。

据我所知，唯一的权衡是我并没有真正遵循真正的 OO 方法，但它再次使代码更加简洁。

有什么理由这不是一种可行的方法吗？以后可能会出现什么样的问题？有一个“工厂”类可以根据需要返回服务和数据层类的实例会更好吗？

这是此问题的特定版本。
我想检查我是否插入了重复的行。我应该在我的应用程序层中以编程方式检查它：

或者我应该捕获数据库层抛出的异常并在我违反约束时触发？

编辑：换句话说：虽然约束仍然存在（无论如何它是很好的数据库设计，我不能确定我的应用程序将是唯一访问表的应用程序）我是否应该依赖约束并处理异常它的违规会加注，还是我还是过牌？

EDIT2：当然我在事务中进行检查+插入，锁定表以确保同时没有其他进程正在写入另一条记录

我环顾四周，看到了一些很棒的代码片段，用于定义规则、验证、业务对象（实体）等，但我不得不承认，我从未见过完整的优秀且编写良好的业务层。

我只知道我不喜欢什么，但不知道什么是伟大的。

谁能指出一些好的 OO 业务层（或出色的业务对象），或者让我知道他们如何判断业务层以及是什么让一个业务层变得出色？

谢谢

我们有一个分层的应用程序，或者至少正在过渡到一个，分解如下：

• 接口（用户接口或应用程序接口，即webservice等）
• 商业逻辑
• 数据访问

为了使这个问题的其余部分更加具体，我将描述一个具体的例子。

我们有一个用户界面，它背后有一个控制器对象（业务逻辑层）。该控制器通过另一个对象（数据访问层）与数据库通信。

在给定的上下文中，用户界面允许用户选择一个员工来绑定正在执行的操作。由于有关于用户（实际上是控制器之外的任何世界）可以选择哪些员工的规则，控制器为此提供了两件事：

• 一个可读的属性，其中包含可供选择的可用员工列表
• 包含当前选择的员工的读/写属性

用户界面可能会读取列表并使用它来填充组合框。

在此应用程序的版本 1 中，组合框包含员工的识别号 + 员工的姓名。

一切都很好...

...直到版本 1.1，一个错误修复。用户抱怨他无法在Jimmy Olson和Jimmy Olson之间进行选择，因为该应用程序无法让他轻松地知道哪个是哪个。他知道销售部门有一个 Jimmy，开发部门有另一个，所以这个 1.1 版本的解决方法是简单地在组合框中添加一个斜线 + 部门名称。在版本 2 中，我们会选择将组合框替换为具有列支持的组合框，删除斜线，但在 1.1 中，选择此选项是为了最大限度地降低出现更多错误的风险。

换句话说，组合框将包含：

• 1 - 吉米奥尔森/销售
• 2 - 吉米奥尔森/发展
• • 其他人

但是，用户界面代码没有 SQL 代码，也没有任何方法可以控制该部门，因此我们必须到控制器那里查看代码。控制者不需要部门，说实话，连员工的名字都不需要，身份证号码就够了，所以控制者里面没有任何东西向部门索要或做什么。所以我们必须深入到数据访问层并在那里更改 SQL。

坦率地说，这个解决方案很臭。

如果这个控制器有多个接口，有不同的要求，我们有三种可能的解决方案：

1. 更改数据访问层以满足多个接口（2 层之外）的（增加/多样化）需求，这意味着所有接口都可能获得它们需要的所有数据，但它们也将获得任何所需的所有数据其他接口的
2. 添加一些东西，让用户界面告诉数据访问层（仍然是 2 层）它需要什么
3. 以某种方式使用户界面层获得所需的数据，而无需更改所涉及的控制器或访问层，这听起来像是我们需要更多的数据访问代码，某处。

以上解决方案都感觉不好。

我想知道的是，我们完全偏离轨道了吗？你会怎么做？在上述 3 之下是否有第四和第五种解决方案？

根据这个问题：Separation of Concerns，接受的答案包含以下引用：

关注点分离就是将每个关注点的代码分开。更改接口不应该需要更改业务逻辑代码，反之亦然。

这是否仅仅意味着所有控制器/数据访问层应该为我们提供完成其工作所需的一切（即员工的识别号），然后用户界面应该与数据库对话并询问更多信息关于这些特定的员工？

我想创建一个可以在本地和在线上运行的游戏。

我的第一个想法是创建一个接口，该接口将包含 GUI 业务逻辑所需的所有方法，然后具有网络实现和本地实现。

这适用于请求-响应消息。但是服务器发送的消息呢，我必须更新一些 GUI 组件（即 JLabels）？

我的第一个解决方案是实现监听器，实现中的每个更改都会触发一个事件。GUI 将适当地注册和更改其组件。但是，在业务逻辑中调用触发事件看起来有点不对劲。

我在正确的轨道上吗？因为我觉得我不是。有什么建议么？

谢谢你。

注意：客户端是一个简单的 Java Swing GUI。

DTO

我正在构建一个希望扩展到许多用户的 Web 应用程序。此外，我需要通过 Web 服务向受信任的第三方公开功能。

我正在使用 LLBLGen 生成数据访问层（使用 SQL Server 2008）。目标是构建一个业务逻辑层，使 Web App 免受 DAL 细节的影响，当然，还提供 DAL 之外的额外验证级别。此外，据我现在所知，Web 服务本质上将是 BLL 的薄包装器。

当然，DAL 有自己的一组实体对象，例如 CustomerEntity、ProductEntity 等等。但是，我不希望表示层直接访问这些对象，因为它们包含特定于 DAL 的方法，并且程序集特定于 DAL 等等。因此，这个想法是创建数据传输对象 (DTO)。这个想法是，本质上，这些将是普通的旧 C#/.NET 对象，它们具有所有字段，例如 CustomerEntity，实际上是数据库表 Customer，但没有其他东西，除了一些 IsChanged/IsDirty 属性。因此，会有 CustomerDTO、ProductDTO 等。我假设这些将继承自基本 DTO 类。我相信我可以使用 LLBLGen 的一些模板生成这些，但我还不确定。

因此，这个想法是 BLL 将通过接受和返回这些 DTO 对象来公开其功能。我认为 Web 服务将处理将这些对象转换为 XML 以供使用它的第三方使用，许多可能没有使用 .NET（此外，有些东西可以通过 Web 应用程序上的 AJAX 调用使用 JSON 进行脚本调用）。

我不确定设计这个的最佳方法以及如何前进。这里有一些问题：

1）这应该如何暴露给客户端（表示层和Web服务代码）

我在想会有一个具有这些方法的公共类，每次调用都是原子操作：

InsertDTO、UpdateDTO、DeleteDTO、GetProducts、GetProductByCustomer 等等...

然后客户端只需调用这些方法并传入适当的参数，通常是 DTO。

这是一个好的、可行的方法吗？

2）从这些方法返回什么？显然，Get/Fetch 类型的方法将返回 DTO。但是插入呢？部分签名可能是：

但是，插入时应该返回什么？我想收到错误通知。但是，我对某些表使用自动递增主键（但是，一些表具有自然键，尤其是多对多表）。

我想到的一个选项是 Result 类：

因此，在插入时，DTO 将获取其获取 ID（如 CustomerDTO.CustomerID）属性集，然后放入此结果对象。如果 Result.Error != null 客户端将知道是否有错误，然后它会从 Result.AffectedObject 属性中知道 ID。

这是一个好方法吗？一个问题是，它似乎在来回传递大量冗余数据（当它只是 ID 时）。我不认为添加“int NewID”属性是干净的，因为某些插入不会有这样的自动递增键。另一个问题是我认为 Web 服务不能很好地处理这个问题？我相信他们只会在 Result 类中返回 AffectedObject 的基本 DTO，而不是派生的 DTO。我想我可以通过拥有大量不同类型的 Result 对象（可能从基本 Result 派生并继承 Error 属性）来解决这个问题，但这似乎不太干净。

好吧，我希望这不是太罗嗦，但我想清楚。

我刚刚开始为个人项目玩弄/学习 NHibernate，并且觉得我没有“得到”一些东西。我习惯于让应用程序像这样工作：

表示层 --> 业务层 --> 持久层。例如，我的表示层将调用 BusinessLayer.GetCustomer(id)。在该方法中，我将检查调用者是否有权获取客户。好的，这仍然适用于 NHibernate。不过，我的问题是我如何对更新、添加和删除有任何安全性？例如，假设我想修改我得到的客户。通常，我会这样做：

同样，UpdateCustomer 方法将检查您是否可以更新此客户。好的，但是使用 NHibernate，要更新客户，我只需设置 FirstName。然后我不需要调用更新，因为它都是透明的。这就是 Hibernate 的正确之处：“透明和自动持久性”。那么，如何通过这种透明度进行安全检查呢？我只是不相信自己足够不会犯错误并做类似的事情：

哎呀。我刚刚清除了数据库中所有客户的姓名。这是人为的吗？是的。现在，如果我有某种 BusinessLayer 检查到位，这只会引发异常，因为该用户无法更新其他用户的名称。

另一个问题。假设我是管理员，并且可以在系统中做任何事情，并且我有这样的代码：

好的，所以在这里我只是想过滤订单，但我不小心把它们从数据库中删除了。透明度导致我做了一些非常糟糕的事情。如何减轻这种风险？

我真的很想使用 NHibernate，但我不想以错误的方式使用它。帮助！:)

我需要一个简单的模式来完成上述操作。有几点需要注意：

1）我有一个类，我必须使用它来进行实际数据检索并返回 DataTable

2）我不关心支持所有可能的数据库类型的通用接口，我们坚持使用一种数据库类型。

3）我如何优雅地捕获错误并通知用户发生了错误。

4) 不要让我学习 MVC - 现在不是一个选择。

我对实际的图案设计很感兴趣。