开发人员可以使用许多不同的选项，需要向其应用程序添加数据访问层（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时，VS中的Code Smith，MyGeneration和T4模板工具等工具可以提供很大的帮助。