第.Net层开发的体系结构问题

大家好，我对分层开发过程非常陌生。我目前正在开发一个应用程序，我有一些关于当今技术的最佳实践/架构问题的基本问题。我将使用WCF作为服务层。请注意，我正在尽可能地将事物解耦。我不希望上层的任何东西都必须知道下层的任何东西，这也是我不喜欢LINQtoSQL或实体框架的原因之一

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

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

老实说，这两种解决方案我都不喜欢。如果您决定每个视图的专用逻辑，那么您需要为每个视图创建一个POCO对象（假设您将返回一个POCO对象数组）。如果您以后决定需要向其中一个视图添加更多列，那么您将破坏现有代码（因为您更改了POCO上的接口）。如果您决定返回每个表的视图，并尝试将其合并到业务层中，那么这可能会变得非常混乱。TSQL具有连接，原因如下：）。此外，根据您的设计，您可能会返回比您需要的更多的数据，这将是低效的

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

---

Ncage

我认为您不想让数据层了解业务或UI层的想法有点遗漏。在ORM工具（例如LINQ到SQL）中，实体的属性由数据决定。没有理由不这样做。拥有强类型实体与在数据层中拥有业务/UI逻辑不同，通常是一件好事；你如何到达那里取决于你自己

我一直主张使用强类型组件来传递数据，而不是像DataSet/Table/Row/View等这样的通用存储库

---

也许你可以进一步说明是什么让你远离这种方法？

这些都是很好的问题。有很多可能的答案和很多可能的架构。我建议你读一本这方面的入门书。它是免费的，全面的，并且深入讨论了你提出的问题。没有一个体系结构指南是完美的，但作为起点，我认为学习基础知识不会出错。

好问题。重要的东西，这个。通常，采用分层解决方案的最佳方法之一是查看接口。接口是提供“阻塞点”的一种方式，可用于多种用途

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

我提出这一点（这是相关的），因为在定义接口时，还需要定义在层之间传递的数据。因此，在定义各层之间需要发生的事情时，您最终要定义传递的数据；同时，定义一组严格的传递数据

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

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

---

当然，要正确地做到这一点，从长远来看要解决的问题是有益的；用户希望执行的操作集是什么？这些操作通常将自己分解为“动词”，这些动词很好地映射到定义业务对象将实现的契约的接口定义。业务对象将操作的数据集将定义您需要在数据库上拥有的视图集。通过这种方式，您可以干净地保持您的分离。

谢谢JP我将查看模式和实践指南，看看它们是否有助于我这样思考……如果您这样设计您的系统，那么您必须在业务层和客户层中引用您的数据层。这个设计好吗？如果因为向数据库添加了列而中断了数据层上的接口，该怎么办。您刚刚破坏了每个客户端，并且必须将更改部署到N个客户端，除非您不返回匿名类型。您也不能跨层（WCF）传递datacontext对象，但是上面提到的是上层不知道下层，而不是下层