【发布时间】：2012-02-09 09:37:42
【问题描述】：
我已经构建了 Windows 窗体，但我有一些问题。
我想知道为什么我们必须从头开始构建数据访问层，尽管 Visual Studio 可以为此生成代码。
两者的优缺点是什么？
每个解决方案应该使用什么情况？
【问题讨论】：
标签： c# database visual-studio data-access-layer
【发布时间】：2012-02-09 09:37:42
【问题描述】：
对于需要向其应用程序添加数据访问层 (DAL) 的开发人员，有许多不同的选项可供选择。我在这里假设当您说“Visual Studio 可以为此生成代码”时，您指的是 Microsoft 的实体框架 (EF)，您可以使用它从模式生成业务对象和存储库（反之亦然） .还有其他方法可以使用 VS 来生成数据访问层（例如，使用 T4 模板和代码生成）。在考虑是否推出自己的数据访问层时，一些因素会发挥作用：
- 时间。可能是最大的因素（在我看来）。有大量参考资料可用于学习在很短的时间内启动和运行 EF 数据层所需的约定。这是将数据导入应用程序的极快途径。过去只是从持久性存储中加载和保存数据，现有框架（如 EF）可以轻松快速地支持事务和缓存等内容。如果编写自己的 DAL，可能需要更长的时间才能从数据存储中获取数据，并且肯定需要更长的时间来测试它，以达到与 EF 相同的程度。
- 功能。您可以通过 EF 获得很多“开箱即用”的功能。将这些添加到您的 DAL 需要一段时间。
- 经验。从头开始编写自己的 DA 层时有很多陷阱——为什么要重新发明轮子？从头开始编写一个好的 DAL 需要一些编码经验才能做好（但这是一个很好的学习经验和一个非常令人满意的项目）
- 控制。如果您希望控制代码的各个方面，您可能更愿意编写自己的 DAL。虽然像 EF 这样的框架可以通过多种方式进行配置，并且适用于许多应用程序，特别是简单的应用程序，但大型应用程序的更复杂的要求（无论是计算复杂还是具有特定的性能配置文件）可能更适合更多可调整的自定义 DAL。例如，您可能不喜欢 EF 生成的 SQL，或者您不喜欢加载子模型的方式。有大量的开源 DAL 为构建提供了坚实的基础，可以轻松连接到 DAL 的任何方面。
- 存在旧代码。在某些极端情况下，如果您在现有应用程序中工作并且需要满足现有的接口要求，或适应现有的数据加载模式，您可能会发现生成自己的 DA 层更容易。此处更可取的替代方法是编写一个适配器层以使您的 DAL 适应现有的应用程序需求，从而将您的 DA 层与遗留代码需求解耦。
如果您确实打算编写自己的 DAL，我当然建议您查看现有的代码生成选项。计划您的架构频繁更改，并能够快速重新生成您的自定义 DAL。从头开始编写 DAL 时，像 Code Smith、MyGeneration 和 VS 中的 T4 模板工具这样的工具可以提供很大的帮助。
【讨论】：