我应该在数据库或数据访问层中生成复杂对象吗？

Question

我正在为我们其中一个包含医疗数据的部门申请。它与我们在这里的第三方系统连接。

对象本身（声明）并不是非常复杂，但由于数据的性质和数据库的组织，检索声明数据非常复杂。我不能简单地将所有表连接在一起并获取数据。我需要做一个“基础”查询来获取索赔的基础知识，然后根据各种问题拼凑有关索赔的补充数据。

使用这些数据会不会更好：

1. 在存储过程中生成对象，其中所有相关数据都可用，并迭代表变量（使用SQL Server 2005）将所有补充信息拼凑在一起。

2. 在数据访问层中生成对象，我可以在其中使用更强大的数据操作，并进行一系列快速简单的调用以检索查找数据。

3. 使用OR / M工具并绘制出所有复杂情况以生成对象。

4. 其他。

编辑：只是为了澄清下面列出的一些问题。复杂性确实不是业务问题。如果声明为类型代码“UB”，那么我必须从表X中提取一些补充数据。如果声明的类型代码为“HCFA”，那么我必须从表Y中提取一些数据这是那些类型的东西。我希望这会有所帮助。

Answer 1

出于安全原因，我会使用存储过程。您不必为正在使用的声明表提供SELECT权限，这听起来有点重要。您只需要授予用户对该存储过程的访问权限。如果数据库用户已经对表具有SELECT权限，我也没有看到在数据访问层中生成对象有任何问题。只要与您选择的任何选项保持一致。如果您在其他地方使用存储过程，请继续在此处使用它们。这同样适用于在数据访问层中生成对象。

Answer 2

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

Answer 3

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

您要模拟的是一个非常具体的业务逻辑（“什么是声明”），需要在处理声明概念的任何应用程序中保持一致。

如果您只有一个应用程序或多个使用相同中间件的应用程序，您可以将其放在客户端代码中;然而，实践表明，数据库往往比访问它们的软件更长。

在冗余实现中的细微错误和角落情况使不同的应用程序以稍微不同的方式查看数据时，您不希望结束。干，等等。

Answer 4

我不喜欢将业务逻辑推送到持久层，因此我不建议使用选项1.我采用的方法涉及一个定义良好的程序对象，该对象可以为底层数据库实体建模，所以面向ORM，但你的选择3听起来像你认为它是一个繁重的映射任务，我真的不这样做。我只需要有必要的逻辑来加载你在程序对象建模方法中设置的这个对象所关心的任何东西。

Answer 5

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

任何需要业务规则或逻辑（决策）的东西都在我的业务层中。

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

听起来您正在生成的声明实际上是存储在各个地方的数据视图，没有任何决策或业务逻辑。如果是这种情况，我倾向于管理对数据层中数据的访问。

**我永远不会忘记我工作过的一个庞大的系统，它非常过于复杂，因为唯一可以在中心部分工作的人是存储过程的专家......所以很多业务逻辑都结束了那里。*

Answer 6

考虑您计划使用数据的不同方式。应用程序层的整个目的是让您的生活更轻松。如果没有，我同意@hoffmandirt的说法，它在数据库中更安全。

Answer 7

Stored procedures are bad, m'kay?

听起来在这种情况下，视图会比存储过程更好。

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

通常，在数据库和应用程序代码之间传播业务逻辑不是一个好主意。

最后，任何解决方案都可能有效。您没有面临成败决定。只是动起来，不要挂在这类问题上。