问题标签 [business-logic]

我想扩展一个由 Linq To Sql 生成的类，以便在创建新对象 (=row) 时进行初始化。

我想在创建父行时向子表添加行。

我希望使用 Oncreated （部分）方法做这样的事情：

每次都从构造函数调用 OnCreated。如果对象将在调用 OnCreated 后从数据库中加载也是如此。而如果对象是从数据库中加载的，则不想执行代码。

那么我在哪里可以在我的模型中添加逻辑来初始化一个对象（-graph）？

[背景]

所以，我有一个 C# 应用程序，它是在我来到这里之前编写的。目前，我不在开发组织中，但我是网络营销组织中我的子组的技术负责人。我的职责是流程自动化、最少的桌面支持和定制应用程序，让我们的生活更轻松。

[/背景]

[应用详情]

我们有一个从 URL 列表创建自定义数据库文件的应用程序。它被设计为有一个输入文件和两个输出文件，用于使用这些类型的 db 文件的两个应用程序。两个输出文件之间的差异规则被编译到代码中。

[/应用详情]

内部 C# 应用程序是否应该使用在不重新构建的情况下无法更改的业务逻辑进行编译？

您目前使用什么软件来实现业务逻辑？

我们有一个具有非常繁重的业务逻辑的应用程序，它是用 Java 和 POJO 和 EJB (2.0) 实现的。

是否有任何更新的软件语言或工具有利于用于编写业务逻辑？

我们正在构建一个面向服务的系统，我们将应用程序分为几个层：

1. SOAP Web 服务（例如 BuildingService.asmx）
2. 业务逻辑层（例如 BuildingXXX）
3. 数据访问层（例如 BuildingProvider）
4. 类型（例如，建筑）

SOAP Web 服务只是从业务逻辑层实例化一个 BuildingXXX 类型的对象，以便将实现排除在 SOAP Web 服务之外。BuildingXXX 然后使用来自数据访问层的 BuildingProvider 返回在数据传输对象层中定义的类型。

我们一直无法确定我们应该在业务逻辑层中调用什么对象。

命名这些业务级实体的“标准”命名约定是什么？

我正在尝试做一些事情，如果有两个类（我关心），一个叫做 Inquiries，另一个是 InquiryStatus 的外键表

我的业务逻辑是什么我试图检查 Inquiry 是否与具有 InquiryStatus.bln_requiresValue 的新 InquiryStatus 相关联，那么我需要有一个 Inquiry.Money

现在我有

但是 Ekey 总是为空的，所以 InquiryStatusReference.EntityKey

我们正在开发一个提供 API 接口的产品，以便其他开发人员可以使用主要产品的某些功能。

这已经实施并记录在案。

但我不确定这是否非常有用，并且文档对于开发人员来说非常清晰。

我们如何找到人来评论这个功能？应该是什么样的人？

从某种意义上说，我们正在为单个功能/组件寻找产品负责人。是否可以？

我正在学习 ASP.NET MVC，我喜欢它。但是，我对为模型命名空间的正确方法感到非常困惑。

在剖析 NerdDinner 示例应用程序时，我注意到 Models 文件夹中的所有内容都属于 Models 命名空间。数据映射类、存储库、错误规则管理等属于同一个命名空间级别。

我知道这个文件夹的灵感来自于 Rails 和朋友等框架，并且需要证明 MVC 标题中的 M 是正确的，但是；自动模型命名空间不会破坏编写可跨不同系统和实现可拆卸和可移植的业务逻辑的任何机会吗？

我应该在此模型命名空间下命名我的业务逻辑，还是应该完全忽略它并以更独立于框架的方式对我的类进行分类？

是否有任何复杂而优秀的 ASP.NET MVC 示例应用程序可以证明这一点？

我有一个重 CRUD 的 ASP.NET 应用程序，其中包含存储过程中的所有业务逻辑。

例如，有一个大约 500 行长的 UPDATE 存储过程，包含大量条件逻辑，引用多个表和 UDF。proc 接收正在更新的字段名称和新值，设置一堆声明的变量，进行一堆验证并创建一个动态 SQL 语句来进行更新。一旦尺寸适合所有。它很大而且很混乱。

我想将业务逻辑转移到 .NET 端，以便更轻松地管理/更新、测试和置于源代码控制之下。

我的问题是：这个业务逻辑应该去哪里？

假设我有一个带有名为“Factory”的属性的 PurchaseOrder 对象。如果工厂发生变化，我需要确保分配的新工厂生产采购订单上的产品，它有定价，并且根据该工厂要求的最低数量等。所有这些验证都需要在数据库。

我是否应该让 PurchaseOrder 对象的工厂设置器负责通过“isFactoryValid”方法/属性进行数据验证，该方法/属性对通用数据访问对象进行多次调用，然后进行更新（如果是）？

或者我是否创建一个负责处理与 PurchaseOrder 相关的数据访问的 PurchaseOrder/Database '代理'对象。在这种情况下，我是否会在由 PurchaseOrder 的设置器调用的代理中拥有一个“isFactoryValid”方法，然后调用代理的更新方法？

我如何确定是否需要担心所有这些额外调用会增加数据库的流量？

假设我有一个大型中间件基础设施，用于调解多个业务组件（客户应用程序、网络、支付等）之间的请求。中间件堆栈负责编排、路由、转换和其他东西（类似于 Gregor Hohpe 的企业集成模式一书）。

我的问题是：把一些业务逻辑放在中间件上是不是很好的设计？

假设我的应用 A 从中间件请求一些客户数据。但为了获取这些数据，我必须提供客户 ID和其他一些参数。这个参数的获取应该由请求的应用程序完成，还是中间件负责“促进”并提供一个接收客户 ID并在内部获取其他参数的接口？

我意识到这不是一个简单的问题（因为业务逻辑的定义），但我想知道这是一种通用方法还是一些指导方针。

是否可以定义 NHibernate.Validator 将使用的验证方法（用于业务规则验证）？我的意思是EntLib中存在的东西：