问题标签 [business-logic-layer]

我正在为我的应用程序构建一个 BLL。从我所见/所读，似乎 BLL 应该是无状态的。这是否意味着所有 BLL 方法都可以是静态的？或者我至少只需要每个 BLL 类的一个实例？出于某种原因，这对我来说似乎很奇怪，所以我想我最好在深入研究我的实验之前检查我没有得到错误的结果。

我还认为这意味着 BLL 对象不应该包含数据，因为数据代表状态 - 因此对于调用的每个 BLL 操作，需要重新查询（或从缓存中获取）所需的任何数据，然后丢弃。那个听起来是对的吗？

谢谢。

首先，在有人大喊大叫之前，我很难用一个简单的标题来概括它。另一个标题可能是“领域模型和 MVC 模型有什么区别？” 或“什么是模型？”

从概念上讲，我将模型理解为视图和控制器使用的数据。除此之外，对于模型的构成似乎有很多不同的意见。什么是域模型、应用程序模型、视图模型、服务模型等等。

例如，在我最近询问存储库模式的一个问题中，有人直接告诉我存储库是模型的一部分。但是，我阅读了其他意见，认为模型应该与持久性模型和业务逻辑层分开。毕竟，存储库模式不应该将具体的持久性方法与模型分离吗？其他人说域模型和MVC模型之间存在差异。

让我们举一个简单的例子。MVC 默认项目中包含的 AccountController。我已经阅读了一些意见，其中包含的帐户代码设计不佳，违反了 SRP 等等。如果要为 MVC 应用程序设计一个“适当的”成员资格模型，那会是什么？

您将如何将 ASP.NET 服务（成员资格提供程序、角色提供程序等）从模型中分离出来？或者你会吗？

在我看来，模型应该是“纯粹的”，可能带有验证逻辑..但应该与业务规则分开（验证除外）。例如，假设您有一条业务规则，规定在创建新帐户时必须向某人发送电子邮件。在我看来，这并不真正属于模型。那么它属于哪里呢？

有人愿意解释这个问题吗？

假设我有一堂课

现在在我的数据层中，我正在尝试编写代码，该代码将创建一个 IDataCommand 实例并将 FooId 设置为命令参数之一，如下所示

如果您注意到代码行 - param.value=(f.FooId >0)?f.id:(object)DbNull.Value; . 我的问题正是在这个领域。如果我要提供的参数太多。当我在每个参数上检查这样的值时，它看起来有点糟糕。这里的问题是做这种事情的最佳方法是什么？谁应该做DL或BL？如果是 BL，那么它应该在那里分配 DBNull 值吗？有没有其他标准方法可以做到这一点？

I need a BindingList in my UI to provide two-way databinding between my collection and a DataGridView. However, it doesn't seem correct to return a BindingList from your business layer (or domain layer, service layer, data layer, etc.). That is, I'd only be using a BindingList because of a UI requirement, and now this UI need would be coupled with my domain layer.

What is the "proper" decoupled way to do this? Should I be returning an IList and then copying it into a BindingList for presentation purposes? From a real world perspective, is this overhead worth anything?

我的用户层中有一个 gridview，它使用业务层方法作为其数据源，我希望 gridview 支持分页和排序。当我从该方法返回一个 Ienumerable 时，它​​将带回所有数据。如果我使用 Take/Skip 只带回一页的价值，gridview 不会意识到有很多页的数据。

当我将 Ienumerable 更改为 IQueryable 时，DataBind() 失败，因为数据已被处理掉。我认为这个问题与查询实际执行的时间有关，它可能与我应用于查询的过滤器有关（见下文）。

用户层代码：

业务层代码：

考虑一个现有的数据访问和业务逻辑层，该层被多个不同的应用程序使用，并且到目前为止，在任何使用它的给定应用程序的生命周期内只需要一个数据连接 - 所以连接信息可以简单地由数据提取应用程序配置文件中的层。然而，展望未来，数据和逻辑类需要为应用程序提供灵活性，以便在每次调用的基础上确定数据连接。更重要的是，这些类现在被多个应用程序通过服务同时调用。

调用者不想专门管理连接字符串，而是希望以枚举形式的连接名称可以解析为数据层中的连接字符串。

目前，所有数据和逻辑类都是静态的，数据范围为内部，逻辑范围为公共。

考虑到 API 可用性、性能、线程安全/调用者隔离等因素，有哪些好的策略可以从调用者一直到数据类中的方法获取密钥？

两个明显的选择是：

1. 将连接键作为参数添加到所有方法。糟糕 - 不会发生，但包括完整性。

2. 将逻辑和数据类更改为实例类，并在构造函数中传递密钥以供任何成员方法使用。不会有方法签名更改，而是对 API 的调用方式进行重大更改。

还有哪些其他选择？

我正在实施 3 层架构。我只是想知道业务层在三层架构中的作用。

我正在使用实体框架开发应用程序。所以我有可以在 PL、BL 和 DL 中访问的实体对象。我的问题是实体对象的输入分配是否应该在 PL 或 BL 中。（考虑有保存方法）

我不想创建一个新类并决定使用匿名类型来将数据从表示层发送到业务层。

但我的问题是如何在 biz 层中引入匿名类型？我使用 Vb.Net 2008 和 VS 2008。

编辑

实际上，我必须处理一些数据，它们的性质实际上是临时类，我不会在我自己的项目中再次使用它们。

我使用 Entity Framework 4.0 来创建我的数据访问层。然后我发现我的业务逻辑层具有与 DAL 相同的对象，但有一些扩展（即，更多属性、一些函数和 setter 处的数据验证......）。

我计划在单独的项目中使用 DAL 和 BLL，并正在寻找在 BLL 中使用实体类并防止代码冗余的最佳实践。

当我搜索时，有两个主要想法：

1. 通过部分类扩展同一项目内的实体类
2. 使用接口（由实体类和相关的 BLL 类实现）。前者在程序员中更受欢迎。

上述解决方案的缺点：

1. 我们需要在同一个项目中添加代码作为部分类的一部分。这适用于添加属性和方法，但不适用于覆盖某些内容（即，在业务逻辑层设置属性之前添加验证）
2. 如果实体模型发生更改，我们需要再次手动从实体类中提取接口，并且还需要对 BLL 相关类进行另一次更改（两次手动解决）。

我的问题是为什么我们根本不从相关实体类继承我们的 BLL 类并扩展/覆盖它们的方法和属性？

在 Rails 中实现“业务规则”的方法是什么？

假设我有一辆车并想卖掉它：

car.sell方法将检查一些事情：

我正在考虑创建一个名为 Rules 的类：

并像这样使用它：

至于获取current_user，我正在考虑将其存储在全局变量中？我认为每当调用控制器动作时，它总是一个“新鲜”的调用，对吗？如果是这样，那么将当前用户存储为全局变量不应该带来任何风险..（就像其他用户能够访问其他用户的详细信息一样）

任何见解表示赞赏！

更新

所以，全局变量路由出来了！感谢 PeterWong 指出全局变量仍然存在！

我现在正在考虑使用这种方式：

Rules.can_sell_car?(current_user,@car)然后从控制器动作中调用。对这种新方式有什么想法吗？