问题标签 [business-logic]

这是“分析瘫痪”似乎已经站稳脚跟的场景之一，所以请指教！

该项目

一个相当简单的汽车产品列表，其中包括零件参考、适合的车辆等详细信息。

前端是一个 asp.net MVC 应用程序。

后端是 SQL，使用 Subsonic 将产品投影到域对象中。

功能性

我们的屏幕之一是产品详细信息屏幕。ASP.NET MVC 控制器调用产品存储库以检索产品详细信息，将这些详细信息（通过一些自动映射到 viewModel）返回到视图。

现在的杀手锏是我们有两个或三个频道进入网站，根据频道的不同，用户需要看到不同的零件编号。

例如，如果是零售渠道，则零件编号与数据库中的零件编号相同，但如果用户通过贸易渠道访问该站点，则零件参考的开头将替换为替代编号。

例如，如果通过交易频道查看，则 0900876 将变为 1700876。

我正在努力的地方是决定在哪里封装关于部件引用（以及其他可能改变的细节）的“通道规则”。

我已经考虑过这些替代方案。

将逻辑直接写入领域对象

在Product类上，我们可以有一个方法/属性来获取翻译后的部分参考。

在这种情况下，Product 实例必须知道通道，这对我来说似乎是错误的。

将逻辑封装在另一个对象中

我们可以编写一个类来处理这部分参考翻译，或者创建一个包含此逻辑的Channel类。

我不明白的是如何协调这两个班级。

如果控制器调用存储库来检索产品，那么它是否应该确定使用了哪个通道并翻译部件参考？如果是这样，我如何将带有翻译部分参考的产品发送回视图？

还值得注意的是，这部分参考也必须出现在搜索结果和其他场景中，因此我认为它需要整齐地包含在某个域中。

我遇到了一种情况，我敢肯定，我的业务规则文档分布在电子邮件、文档（现已过期）和即时消息中。这很臭。

我可以想到 2 个替代方案：Sharepoint（讨厌它，搜索功能很糟糕）或 wiki。

我希望在理想解决方案中看到的一些东西：

• 易于更新：不要让我打开 Word 来更新文档
• 差异视图：有时您只需要查看新内容
• 可订阅：逐页通知新更改
• 基于角色：页面的编辑和查看可以绑定到角色
• 附件：轻松包含模型、文件等。
• 搜索：这是一个post google world，我希望能够立即搜索和找到——Sharepoint在这个类别中输了，除非我们使用的那个配置不正确
• 附件限制：理想情况下，该解决方案不允许上传一堆我们称为文档的 Word 文档。我希望文档具有一致（且简单）的格式。强制附件为 PDF、txt 等。

跟进我的 wiki 评论，看起来至少有 3 个 wiki可以满足我的需求（Incentive、SharePoint-Wiki-Plus、ThoughtFarmer）。ThoughtFarmer，喜欢这个名字。

当使用外观设计模式来构建应用程序的业务 EJB 层时，我们为什么还要使用会话 bean 来实现实际的业务逻辑？不只是使用普通的 Java 类（如果不需要容器管理注入）是否有特定的原因？普通 Java 类与会话 bean 的性能如何，绕过业务会话 bean 不会提高性能吗？

总结一下这两种选择：

1. 客户端 -> 外观 -> 会话 Bean
2. 客户端 -> 外观 -> 常规 JAVA 类

为什么使用 1 而不是 2？

我对有关客户端验证或模型绑定的答案不感兴趣。确实，这个问题可能适用于 MVC 之外的任何数据访问类库，但我认为问题是相似的。

我目前正在使用存储库模式与我的实体（模型）进行数据访问。目前，存储库处理所有 CRUD 操作，但我想我希望我的模型负责保存自己以进行验证。我该如何处理？

我可以在我的模型中添加一个 IsValid 方法，存储库可以调用该方法然后可以在存储库保存模型之前运行我的所有业务逻辑，但是没有任何东西可以强制存储库调用此验证逻辑，对吗？

如果我希望模型有一个 Save 方法，那么他们保存自己的正确方法是什么？他们不应该回电到存储库吗？

关于我应该如何处理这个问题的任何想法？

谢谢！

我正在浏览各种 WPF 文档，我感到不必要的困惑。“业务逻辑”一词散布在其中，好像每个人都应该知道它是什么。

根据这里的这个问题，我可以看到什么是业务逻辑： 应用程序中的“业务逻辑”到底由什么组成？

但是这个词是从哪里来的呢？为什么它被称为“业务逻辑”而不是“核心逻辑”或“主要算法”或任何其他更通用的术语？我编写的程序很少与“业务逻辑”有关，当我想到“业务逻辑”时，我会想到处理信用卡交易、客户数据库维护等的事情。换句话说，与整个计算机科学的一小部分相关的事物。当我编写一个成像应用程序时，没有涉及“业务”，没有客户，没有基于金钱的交易，什么都没有。所以说我有“业务逻辑”真的让我很困惑，因为我不是在做生意，我是在处理图像。

我经常在 Web 开发方面看到短语“业务逻辑”和“应用程序逻辑”（我认为它也适用于一般编程，而不仅仅是 Web 开发）。

这对我来说很新，所以我真的不知道这是什么意思，谁能解释一下这到底是什么意思？它只是程序员使用的“流行词”吗？或者？

我正在为一种对可定制、灵活的业务规则有很大要求的案例管理系统设计一个应用程序。我计划在没有工作流的情况下使用 WF 规则引擎（请参阅：here，以及其他示例等）。

我的客户提出的观点之一（这是有道理的！）是是否存在将规则引擎用于没有工作流的业务规则引擎的现有示例。

我的问题当然是：以前有没有人在生产应用程序中使用过 WF 规则引擎无工作流，您的经验是什么？

我想要一个 SQL 查询来检查给定的时间戳是否在企业的营业时间内。这些营业时间根据一年中的时间（季节性时间）而变化，并且在某些假期关闭业务。我有这些日期的列表，尽管它们可能会发生变化。

我想要的是一个在数据库中存储这些信息的好结构和一个看起来像这样的函数：

我会plpgsql在 PostgreSQL 8.2.x 上写这篇文章，如果这有什么不同的话。

我正在考虑重写应用程序的数据模型更新方法的一部分，以包括对注册来自数据库的事件的支持。有什么理由说明这是一个坏主意吗？我应该限制自己接收由 CRUD 操作触发的事件，还是可以围绕事件通知编写更多业务逻辑？潜在的陷阱是什么？

我在这里寻找指针和信息，我会制作这个 CW，因为我怀疑它没有一个正确的答案。这是针对 C# 的，因此我将在下面对 Linq 进行一些引用。我也为这篇长文道歉。让我在这里总结一下问题，然后是完整的问题。

总结：在 UI/BLL/DAL/DB 4 层应用程序中，如何更改用户界面，显示更多列（例如在网格中），避免通过业务逻辑层泄漏到数据访问层，以获取要显示的数据（假设它已经在数据库中）。

让我们假设一个具有 3(4) 层的分层应用程序：

• 用户界面 (UI)
• 业务逻辑层 (BLL)
• 数据访问层 (DAL)
• 数据库（DB；第 4 层）

在这种情况下，DAL 负责构造 SQL 语句并针对数据库执行它们，返回数据。

是“正确”构建这样一个层以始终执行“选择*”的唯一方法吗？对我来说，这是一个很大的禁忌，但让我解释一下为什么我想知道。

假设我希望在我的 UI 中显示所有拥有有效就业记录的员工。“活动”是指就业记录从开始到日期包含今天（或者甚至可能是我可以在用户界面中设置的日期）。

在这种情况下，假设我想向所有这些人发送电子邮件，所以我在 BLL 中有一些代码可以确保我还没有向同一个人发送电子邮件，等等。

对于 BLL，它需要最少的数据量。也许它会调用数据访问层来获取活跃员工的列表，然后调用来获取它已发送的电子邮件列表。然后它加入这些并构造一个新列表。也许这可以在数据访问层的帮助下完成，这并不重要。

重要的是，对于业务层来说，它需要的数据真的不多。也许它只需要两个列表的每个员工的唯一标识符进行匹配，然后说“这些是那些活跃的人的唯一标识符，你还没有发送过电子邮件”。然后我是否构建 DAL 代码来构建仅检索业务层需要的 SQL 语句？IE。只是“从员工那里选择 id ...”？

那么我该怎么做用户界面呢？对于用户而言，最好包含更多信息，具体取决于我要发送电子邮件的原因。例如，我可能想包括一些基本的联系信息，或者他们工作的部门，或者他们的经理姓名等，而不是说我至少要显示姓名和电子邮件地址信息。

UI 如何获取这些数据？我是否更改 DAL 以确保将足够的数据返回给 UI？我是否更改 BLL 以确保它为 UI 返回足够的数据？如果从 DAL 返回到 BLL 的对象或数据结构也可以发送到 UI，那么 BLL 可能不需要太多更改，但是 UI 的要求会影响层超出它应该与之通信的层. 如果这两个世界在不同的数据结构上运行，则可能必须对两者进行更改。

那么当 UI 发生变化时，为了进一步帮助用户，通过添加更多列，我必须/应该多深才能更改 UI？（假设数据已经存在于数据库中，因此不需要更改。）

提出的一个建议是使用 Linq-To-SQL 和 IQueryable，这样如果处理什么（如在什么类型的数据中）和为什么（如在 WHERE 子句中）返回 IQueryables 的 DAL，BLL 可以可能会将这些返回到 UI，然后 UI 可以构造一个 Linq 查询来检索它需要的数据。然后，用户界面代码可以拉入它需要的列。这会起作用，因为使用 IQuerables，UI 最终会实际执行查询，然后它可以使用“select new { X, Y, Z }”来指定它需要什么，甚至在必要时加入其他表。

这对我来说看起来很乱。UI 自己执行 SQL 代码，即使它隐藏在 Linq 前端之后。

但是，为了发生这种情况，不应该允许 BLL 或 DAL 关闭数据库连接，并且在 IoC 类型的世界中，DAL 服务可能会比 UI 代码想要的更快地被处理掉，所以Linq 查询可能只是以“无法访问已处置的对象”异常结束。

所以我正在寻找指针。我们离我们有多远？你是如何处理这个问题的？我认为对 UI 的更改会通过 BLL 泄漏到 DAL 中的事实是一个非常糟糕的解决方案，但现在看起来我们无法做得更好。

请告诉我我们有多愚蠢并证明我错了？

请注意，这是一个遗留系统。多年来，更改数据库架构并不在范围内，因此使用 ORM 对象的解决方案基本上相当于“选择 *”并不是一个真正的选择。我们有一些大表，我们希望避免拉起整个层列表。