问题标签 [business-logic]

我有一个 BO 方法，它必须执行两个操作才能履行其合同。

1. 在数据库中插入一条记录
2. 发送包含记录元数据的电子邮件通知

两者都是通过调用负责完成操作的各个 DAO 方法来处理的。

我不会在我的 DAO 中捕获异常，我会在 BO 中处理和发布它们。第一次调用是对 DAO 进行插入，并且可以抛出 NullReferenceException 或其中一个 sql 异常。email 方法使用 SmtpClient.Send 可以引发大量异常。

是否可以通过属性强制调用电子邮件功能的子方法仅返回一种类型的异常，即自定义异常？

为了说明这一点：

我可以将每个子方法调用包装在它自己的 try catch 中并抛出我想要的自定义异常，但这只是另一个级别的 try catch 被 AddSupportTicket 中的另一个 try catch 捕获，然后在 UI 中重定向到一个智能错误，所以这对我来说听起来不太好。

我应该如何有效地抛出正确的自定义异常？

拥有在 Visual Dataflex 中实现的具有复杂业务逻辑的单一业务应用程序，我们面临着跨编程语言维护业务逻辑的挑战，因为某些功能是用其他编程语言（主要是 .NET）编写的。

因此，我正在寻找跨不同编程语言实现“同步”业务逻辑的策略，以避免不匹配。避免重复是一个优点，但这可以通过自动化测试来弥补。

编辑：SOA 是一个很好的建议。但是那些服务不够快的情况呢？

编辑 2：对使用元语言有什么建议吗？

我对 c# 相当陌生，正在尝试编写一个 n 层 Web 应用程序。为了确保我将逻辑和代码放在正确的位置，我只是有一个关于将代码放在哪里的问题。

我有三个主要部分：

1. DataAccess 代码 - 在我的 App_Code 文件夹中名为“BusinessLogic”的文件夹中。

2. 业务逻辑代码 - 在我的 App_Code 文件夹中名为“DataAccess”的文件夹中。

3. 表示层 - 所有的 UI

例如，如果我需要编写一个 SqlDataReader 来从我的数据库中检索记录，我将在哪里实际编写代码？在 BLL 或 DAL 中？

IE 从表示层我调用 BLL 代码。

这是我开始感到困惑的地方。在我调用的业务层逻辑层中，我是在此处编写 SqlDataReader 代码，还是再创建一个步骤并在数据访问级别编写 SQlDataReader 代码。

IE 在 BLL 中我应该添加一个名为 DAL 的方法吗？例如

然后在我的 DAL 中，我有一种方法来执行实际的 SqlDataReader EG

我一直在尝试从 asp.net 网站上的教程中学习，但是对于教程中的 DAL，他们使用数据集代替。任何帮助将不胜感激。

在 RIA Silverlight 应用程序中放置业务规则的最佳位置在哪里？

我认为域服务将是一个好地方，只是它似乎只与客户端层共享数据。我不认为 ViewModel 是一个好主意，因为我们应该在服务器层有业务规则。

在共享代码中？*.shared.cs?

您将业务规则放在哪里？

我无法弄清楚如何让视图模型收到模型更改的通知，而无需在我的模型中添加一堆特定于 UI 的东西，例如 INotifyProperyChanged 和 INotifyCollectionChanged，或者创建大量不同的事件并做一堆感觉就像它们是特定于 UI 的，应该远离模型。

否则我只需要复制视图模型中的所有业务逻辑以确保一切都是最新的，那么拥有模型有什么意义呢？

我的模型中的一个棘手问题是“类别”类的属性。你可以把它想象成一个树结构，属性都是叶子节点的后代。那么在模型中，属性是通过它的所有孩子递归生成的，这一切都很好。然而，视图模型需要绑定到该属性并且需要知道它何时更改。我应该更改模型以适应视图模型吗？如果我这样做了，那么此时视图模型实际上并没有做任何事情，模型会引发所有必要的更改通知，并且视图可以直接绑定到模型。此外，如果模型是我没有来源的东西，我将如何解决这个问题？

假设您有 3 层：UI、业务、数据。

如果业务层需要访问会话，这是否表明设计不佳？感觉有些不对劲。是否有任何专门针对 Web 应用程序需要遵循的准则？

我使用 c# 2.0 .net

我正在寻找有关如何解决以下设计问题的建议（使用基于 stackoverflow 的虚构示例）。我试图避免一个贫乏的领域模型，并为这种类型的案例寻求一般的“最佳实践”建议。

设想：

假设正在为 stackoverflow 开发一个新功能，只要他/她的问题收到 10 个赞成票，就会向问题的所有者发送电子邮件通知。

域对象模型是这样的：

潜在的实现：

1. 更改AddUpvote()以获取IEmailerService参数并执行AddUpvote()方法内的逻辑。

   /li>

2. 在内部检测此状态AddUpvote()并AddUpvote()从 IoC 容器解析 IEmailService（而不是将 IEmailerService 作为参数传递）。

3. 在调用 的外部服务对象中检测此状态question.AddUpvote()。

   /li>

4. 你更好的解决方案在这里！

我在这里发布了一个关于多语言数据库设计的问题，
[]多语言数据库设计的最佳实践是什么？
我喜欢 Martin 的建议，但现在我有一个问题，创建业务对象的最佳方式是什么？如果我将创建包含 ProductTranslation 对象的产品，那么 UI 中的绑定和工作将会很复杂，如果只有本地化的对象，我将不得不为 CMS 创建不同的对象
非常感谢！

问候！

在基于 Web 的项目上工作是业务规则和逻辑需要由客户定制。我想这样做，而不必每次在系统上注册新客户端时都重新编译应用程序。到目前为止，我概述的架构是：

1. Windows 工作流程：创建动态工作流程并将其保存到数据库。
2. 反射：创建业务规则接口并使用反射加载自定义客户端程序集。
3. 真正的业务规则引擎
4. 实现类似结构图的 IOC 容器。[zaff：添加 6/4]

你有没有实现过类似的东西？如果是这样，你的经验是什么？最后还有另一个我应该探索的解决方案吗？

谢谢你的帮助！！

我有一堂课：时间表。

到目前为止，我喜欢我的 Schedule 课程。但是，我还没有完成检查，我将不得不做一些其他检查：

• locationNum 是数据库中的有效商店编号。
• 是数据库中这 6 个不同的 changeReason 代码之一的 changeReason 文本。
• 等等等等……

通常，我不会在 Schedule 类中编写这些，因为很明显，我不能从此类中调用 DAO。因此，我将有一个业务层和某种验证器类，接受一个 Schedule 类型的对象并按顺序执行一堆数据库验证并收集错误以进行显示/其他。

现在，这是我的问题：

1. 如果您将 Schedule 视为 POJO 并争辩说对象不负责验证自身 - 我将不得不将构造函数中的所有代码移动到业务层的验证器类。但是，如果我要这样做，难道不是日程安排乏力吗？这就是他们所说的违反单一责任原则吗？
2. 假设我将构造函数中的代码移到业务层类中，以便现在所有类型的验证都在我的业务层中。假设有人在我的数据存储中将 dayOfChange 更改为 NULL，现在我正在从我的数据库中加载对象。现在，有了这种对象，我的应用程序可能会崩溃，不是吗？因为假设满足验证规则，我会编写代码。我想我的问题越来越令人困惑，但我想说的是，在这种情况下，我宁愿在构造函数中完成这些检查，以确保 Schedule 类隐藏的数据的完整性。
3. 一般是怎么做的？最佳做法是什么？

感谢您参与本次讨论。