我应该在数据库或数据访问层中生成一个复杂的对象吗?

在这种情况下,对存储过程再进行一次投票。

您试图建模的是一个非常具体的业务逻辑(“什么是索赔”),它需要在处理索赔概念的任何应用程序之间保持一致。

如果您只有一个应用程序,或者有多个应用程序使用相同的中间件,那么您可以将其放入客户机代码中;但是,实践表明,数据库往往比访问它们的软件更长寿。

您不希望出现这样的情况:冗余实现中的细微错误和角情况会使不同的应用程序以稍微不同的方式查看数据。干的,等等。

出于安全原因,我将使用存储过程。您不必为正在使用的索赔表授予选择权限,这听起来有点重要。您只需授予用户访问该存储过程的权限。如果数据库用户已经对表具有选择权限,那么在数据访问层中生成对象也不会有任何错误。只要和你选择的任何选项保持一致。如果您在其他地方使用存储过程,请继续在此处使用它们。这同样适用于在数据访问层中生成对象。

在应用程序的代码层次结构中,将决策/业务逻辑推到尽可能高的位置。ORM/存储过程很好,但不能像手写查询那样高效。代码越高,您就越了解数据的用途,并拥有智能获取数据的信息。

我不喜欢将业务逻辑下推到持久层,所以我不推荐选项1。我将采用的方法包括有一个定义良好的程序对象,它对底层数据库实体进行建模,所以面向ORM,但是您的选项3听起来像是您认为这是一个繁重的映射任务,而我实际上不这么认为。我只需要有必要的逻辑来加载您在方法o中设置的与此对象相关的任何内容。n程序对象建模。

作为一般规则,我使用数据访问层来检索数据(可能来自不同的源),并以有意义的方式返回数据。

任何需要业务规则或逻辑(决策)的东西都将进入我的业务层。

我不会轻易偏离这个选择。

听起来,您生成的声明实际上是存储在不同位置的数据视图,没有任何决策或业务逻辑。如果是这样,我将倾向于管理对数据层中数据的访问。

**我永远不会忘记我所使用的一个巨大的系统,它变得非常复杂,因为只有存储过程方面的专家才能处理中心部件…所以很多业务逻辑最终都是这样的。*

想想你计划使用数据的不同方式。应用层的全部目的是让您的生活更轻松。如果没有,我同意@hoffmandirt的说法,它在数据库中更安全。

Stored procedures are bad, m'kay?

在这种情况下,视图似乎比存储过程更好。

如果您使用的是.NET,我强烈建议您使用ORM来获得对LINQ的支持。

一般来说,在数据库和应用程序代码之间传播业务逻辑不是一个好主意。

最后,任何解决方案都可能奏效。你不会面临成败型的决定。快走,别在这类问题上挂断电话。