.net - .Net 开发层的架构问题

Question

大家好，我对分层开发过程还很陌生。我目前正在开发一个应用程序，我有一些关于当今技术的最佳实践/架构问题的基本问题。我将使用 WCF 作为服务层。请注意，我正在尝试尽可能地解耦事物。我不希望上层中的任何内容必须了解下层中的任何内容，这是我不喜欢 LINQ TO SQL 或 Entity Framework 的原因之一。

1) 在层之间传递数据的最佳方式是什么？我知道数据集或数据表都很容易，但我不认为在层之间传递这个臃肿的数据结构将是最好的解决方案。如果数据表/数据集很大，调试也会变得更加困难。 POCO 对象数组可能是最好的解决方案还是有更好的方法？

2)下一个问题有点棘手。许多应用程序都会有一堆不同的数据 View 。您可能有多个报告、各种数据网格，也许还有一两个图表。您如何为此设计数据层？您是否只是为每个表设计一个“获取”类型的函数，然后尝试将它们组合成有用的 View ，例如业务层中的网格或报告，或者您是否为业务层中需要的每个 View 提供专门的函数。

说实话，我不喜欢这两种解决方案。如果您决定为每个 View 指定专门的逻辑，那么您需要为每个 View 创建一个 POCO 对象(假设您将返回 POCO 对象的数组)。如果您稍后决定需要向其中一个 View 添加更多列，那么您将破坏现有代码(因为您更改了 POCO 上的界面)。如果您决定返回每个表的 View 并尝试将其合并到业务层中，那么这可能会变得非常困惑。 TSQL 具有连接是有原因的:)。此外，根据您的设计，您可能会返回比您需要的更多的数据，这将是低效的。

我还有一些问题，但我会留到以后再说。我不希望这篇文章变得太大:)

Ncage

Answer 1

好问题。重要的事情，这个。一般来说，实现分层解决方案的最佳方法之一是查看接口(interface)。接口(interface)是提供“阻塞点”的一种方式，可以用于多种有用的目的。

在分层解决方案中，接口(interface)用于强制执行各层的行为；通过定义您期望的行为集，您可以有效地解耦各层的实现。也就是说，只要我的层正确实现了接口(interface)，我就根本不需要关心实现。

我提出这一点(并且它是相关的)是因为在定义接口(interface)时，您还需要定义在层之间传递的数据。因此，当定义层之间需要发生什么时，您最终会定义传递哪些数据；同时，定义了一组严格的传递数据。

这里关于隔离的一个相关点是，不应在层之间传递有关层实现的信息。也就是说，通过定义接口(interface)并严格执行，您应该能够从头开始重新实现层的实现，仅了解接口(interface)，并且可以毫无问题地替换其他实现。

知道这一点会让事情变得简单；使用普通旧对象通常会使您的界面保持干净和正确；它可以防止你的数据结构变得臃肿。它还可以防止在另一层中使用有关一层实现的某些信息的诱惑。

当然，要正确地做到这一点，以长远的眼光看待要解决的问题是有用的；用户想要执行的操作集是什么？这些操作通常将自身解析为“动词”，这些“动词”很好地映射到定义业务对象将实现的契约的接口(interface)定义。您的业​​务对象将操作的数据集将定义您的数据库所需的 View 集。这样，你就可以干净利落地维持分离。