构建从头开始的数据访问层vs由Visual studio自动生成的数据访问层

Question

我构建了Windows窗体，并且我有一些问题。

我想知道为什么我们必须从头开始构建数据访问层，尽管Visual Studio可以为此生成代码。

两者的优点/缺点是什么？

每个解决方案应该使用什么情况？

Answer 1

对于需要向其应用程序添加数据访问层（DAL）的开发人员，有许多不同的选项可用。我在这里假设，当你说“Visual Studio可以为此生成代码”时，你指的是Microsoft的实体框架（EF），您可以使用它来从模式生成业务对象和存储库（反之亦然） 。还有其他一些方法可以用来生成数据访问层（例如使用T4模板和代码生成）。在考虑是否推出自己的数据访问层时，一些因素起作用包括：

• 时间。可能是最大的因素（在我看来）。有很多参考资料可用于学习在很短的时间内启动并运行EF数据层所需的约定。这是一种非常快速的将数据导入应用程序的途径。过去只需从持久性存储中加载和保存数据，现有的框架（如EF）可以轻松快速地支持事务和缓存等内容。如果编写自己的DAL，从数据存储中获取数据所需的时间可能会更长，并且测试的时间肯定会比EF验证的时间长。
• 特点。使用EF您可以获得很多“开箱即用”功能。将这些添加到您的DAL需要一段时间。
• 经验。从零开始编写自己的DA层时有很多缺陷 - 为什么要重新发明轮子？从头开始编写好的DAL需要一些编码经验来做好（但是是一个很好的学习经验和一个非常令人满意的项目）
• 控制。如果您希望控制代码的每个方面，您可能更愿意编写自己的DAL。虽然像EF这样的框架可以通过多种方式进行配置，并且可以用于许多应用程序（特别简单的应用程序），但大型应用程序（计算复杂或具有特定性能配置文件）的更复杂的需求可能更适合更多可调节的自定义DAL。例如，您可能不喜欢EF生成的SQL，或者您不喜欢加载子模型的方式。有大量的开源DAL为开发提供了坚实的基础，使得它可以轻松挂接到DAL的任何方面。
• 遗留代码的存在。在某些极端情况下，如果您在现有的应用程序中工作，并且需要满足现有的接口要求，或者适合现有的数据加载模式，则可能会更容易生成自己的DA层。这里最好的选择是编写一个适配器层来使您的DAL适应现有的应用程序需求，从而将您的DA层从遗留代码需求中解耦。

如果您打算编写自己的DAL，我肯定会推荐查看一下存在的代码生成选项。计划您的架构经常更改，并能够快速重新生成自定义DAL。类似Code Smith，MyGeneration和VS中的T4模板工具等工具可以在从头开始编写DAL时提供极大的帮助。