问题标签 [business-logic]

我有一个正在开发的 Web 应用程序，到目前为止，我已经完成了数据访问层。每个表都有自己的类，该类创建该表的行对象，因此每个对象代表表的一行。每个对象的功能基本上都是 CRUD 操作。

我的问题是，为应用程序实现业务逻辑的最佳方式是什么？我在 PHP 中执行此操作，因此我可以只包含一个包含大量函数的文件，但我希望将其组织得更好。数据访问层已经采用了面向对象的方法，所以我想继续这样做。

处理乍一看需要许多嵌套 if 语句的复杂业务逻辑的好方法是什么？

例子：

优惠券。可能：

1a) 价值折扣
1b) 百分比折扣

2a) 正常折扣
2b) 累进折扣

3a) 需要访问优惠券
3b) 不需要访问优惠券

4a) 仅适用于之前已购买的客户
4b) 适用于任何客户

5a) 仅适用于来自国家 (X,Y,…) 的客户

这需要比这更复杂的代码：

即使您将 IF 替换为 switch/case，它仍然太复杂了。有什么方法可以使它可读、可维护、更易测试和易于理解？

好的。所以这是我的简化方案。我们有一个系统可以处理许多客户的订单。我们希望员工用户能够查看所有订单，我们希望客户用户只能查看与其相关的订单。

当尝试查看特定记录时，我们在 OrderSecurity 类中使​​用以下函数：

当我们想要向用户显示订单列表时，我们可以在 OrderService 类中定义以下函数

这对上述情况来说是可以的，但随着规则变得更加复杂，这并不能很好地维持。比如说，我们添加了另一种用户类型，它代表了一个不太受信任的员工，他只能查看来自客户子集的订单。然后，我们必须向 CanViewOrder 和 GetOrders 函数（可能在数据访问类中）添加逻辑，这在我看来违反了 DRY 原则。

所以，我的问题是：我是否在这里遗漏了一个技巧 - 是否有某种方法可以组合业务逻辑以获得在一个地方查看订单的权限，这两个功能都可以使用？

还是我太担心了，应该继续前进，在两个地方都有逻辑？

（在这个特定的应用程序中，我使用的是 ASP Classic - 不要讨厌播放器，讨厌游戏 - 但我会对你如何用任何语言解决这个问题感兴趣）

示例案例：

我们正在使用 SQL Server 构建租赁服务。有关可以租用的物品的信息存储在一个表中。每个项目都有一个状态，可以是“可用”、“出租”或“损坏”。不同的状态驻留在查找表中。

项目状态表：

id 名称
1 '可用'
2 '租用'
3 '损坏'

除此之外，我们还有一条业务规则，该规则规定，无论何时归还物品，它的状态都会从“已出租”更改为“可用”。
这可以通过像“update Items set state=1 where id=@itemid”这样的更新语句来完成。在应用程序代码中，我们可能有一个映射到 ItemState id:s 的枚举。但是，这些包含硬编码的值，可能会导致以后出现维护问题。假设开发人员要更改状态集但忘记修复相关的业务逻辑层......

有什么好的方法或替代设计来处理这类设计问题？
除了直接答案外，还感谢相关文章的链接。

在一个流量合理的网站上，如果应用程序/业务逻辑被编写为存储过程、触发器和视图，而不是 PHP 代码本身，这是否重要？

牢记可扩展性的最佳方法是什么。

目前我们正在使用检查约束来实现业务规则，但我想知道我们是否应该在 SQL 或业务逻辑层（C#）中实现业务规则。我在网上搜索过，发现检查约束很好用。

如果有人知道有关它的更详细信息，请告诉我。另一件事是，可以使用移动应用程序和 Web 应用程序将数据输入我的数据库。

好的，这就是我想要完成的“简而言之”......

我的应用程序的用户可以去创建一个新组。他们可以指定他们将允许/拒绝的其他用户的标准，以确定允许谁加入该组。

示例：年龄：12 - 16 岁身高：5 - 6 英尺

存储规则的数据表如下： Allow or Deny Flag (Y/N) AgeStart: 12 AgeEnd: 16 HeightStart: 5 HeightEnd: 6

然后，我们需要检查用户是否符合条件以确定是否允许他们加入组。

这有意义吗？也可能有与它相反的例外规则......例如第一个“允许：Y”可能是 12 到 30 岁，但第二条记录可能会添加到拒绝 25 到 28 岁，因此用户必须同时满足这两个条件才能进入。

有这个的接盘侠吗？

我想在我的传输对象上使用 DataAnnotations。但是如何在业务层调用它们来验证输入？

这是通过某种方法调用还是反射？

我不使用 ASP.NET，而是使用标准的 ASP.NET，并且想在业务层调用数据注释。

这个问题与技术无关，但我正在使用 C# 和 ASP.NET 并将其用于伪代码。哪种方法更好，为什么？

1. 封装日志、事务和异常处理：

   /li>

2. 将日志记录、事务和异常处理委托给调用者：

   /li>

我担心通过在我的业务逻辑代码中引入对日志记录、事务等的依赖，我会使其不那么通用。另一方面，UI 代码看起来干净多了。我不能打电话。让我知道我应该考虑哪些其他因素。

我有一个业务层，其中包含一些业务对象/POCO/实体/任何东西。我还有一些用于数据访问的存储库。到目前为止，我一直在直接从我的 UI 层访问存储库。我实际上需要更多不是直接 CRUD 的类，因此我将创建一些业务逻辑类来执行逻辑和 CRUD，并且存储库不会被不再是 UI（这可能应该从一开始就完成）。

我应该怎样称呼这些课程？我唯一能想到的是服务类，但我在这个应用程序中有实际的 WCF 服务，所以这会让人感到困惑。WCF 服务也将使用这些类，因此让服务使用服务类似乎很奇怪且令人困惑。