大家好，我对分层开发过程很陌生。我正在开发一个应用程序，我对当今技术的最佳实践/架构问题有一些基本问题。我将使用WCF作为服务层。请注意，我试图尽可能地分解事物。我不希望上层中的任何东西必须知道较低层中的任何内容，这是我不喜欢LINQ TO SQL或实体框架的原因之一。
1）在层之间传递数据的最佳方法是什么？我知道数据集或数据表都很容易但我不认为在层之间传递这种膨胀的数据结构将是最好的解决方案。如果数据表/数据集很大，调试也会更难。也许一系列POCO对象是最好的解决方案还是有更好的方法？
2）接下来的问题有点棘手。很多应用程序都会有一堆不同的数据视图。您可能有多个报告，各种数据网格，也许还有一两个图表。您如何为此设计数据层？您是否只为每个表设计了一个“获取”类型函数，然后尝试将它们组合成有用的视图，例如您的商务层中的网格或报表，或者您是否在商务层中为每个视图配置了专门的功能。
说实话，我不喜欢任何一种解决方案。如果您决定每个视图的专用逻辑，那么您需要为每个视图创建一个POCO对象（假设您将返回一个POCO对象数组）。如果您稍后决定需要向其中一个视图添加更多列，那么您将破坏现有代码（因为您更改了POCO上的界面）。如果您决定返回每个表的视图并尝试将其组合在商务层中，那么可能会非常混乱。 TSQL加入有一个原因:)。您也可能需要返回更多数据，这取决于您的设计效率低下。
我还有一些问题，但我会将其保存到以后。我不希望这篇文章变得很大：）
NCAGE
答案 0 :(得分：5)
好问题。重要的是，这个。一般来说，处理分层解决方案的最佳方法之一是查看接口。接口是一种提供“阻塞点”的方式，可以用于几个有用的目的。
在分层解决方案中，接口用于强制执行层的行为;通过定义您期望的行为集，您可以有效地解除层的实现。也就是说，只要我的层正确实现了接口，实现就是我根本不需要关心的事情。
我提出了这个问题（并且它是相关的），因为在定义接口时，您还需要定义在层之间传递的数据。因此，在定义层之间需要发生的事情时，最终会定义传递的数据;同时，定义一个传递的严格数据集。
这里关于隔离的一个相关点是，不应在层之间传递关于层的实现的信息。也就是说，通过定义您的接口并严格执行实现，您应该能够使得层的实现可以从头开始重新实现，只知道接口，并且可以毫无问题地替换其他实现。
知道这一点很简单;使用Plain Old Objects通常可以保持您的接口清洁和正确;它可以防止您的数据结构变得臃肿。它还有助于防止使用某些有关在另一层中实现一层的信息的诱惑。
当然，要正确地做到这一点，从长远来看待解决的问题是有用的;用户想要做的操作集是什么？这些操作通常将自身解析为“动词”，这些动词很好地映射到定义业务对象将实现的合同的接口定义。业务对象将在其上运行的数据集将定义您需要在数据库上拥有的视图集。通过这种方式，您可以干净利落地保持分离。
答案 1 :(得分：2)
这些都是非常好的问题。有很多可能的答案和很多可能的架构。我建议您阅读有关该主题的入门读物。 Patterns & Practices has a very good one。它是免费的，全面的，并深入讨论您提出的问题。没有一个建筑指南是完美的，但作为一个起点，我认为你不会错误地研究基础知识。
答案 2 :(得分：0)
我认为您不想让数据层知道有关业务或UI层的任何信息。在ORM工具（例如，LINQ to SQL）中，实体的属性由数据确定。没有理由不这样做。具有强类型实体与在数据层中具有业务/ UI逻辑不同，并且通常是好事;你如何到达那里取决于你。
我总是提倡使用强类型组件来传递数据，而不是像DataSet / Table / Row / View /等通用存储库。
也许你可以稍微扩展一下你从这种方法中吸引的东西？