从头开始构建数据访问层与 Visual Studio 自动生成数据访问层

发布于 2024-12-26 07:22:56 字数 141 浏览 3 评论 0原文

我已经构建了 Windows 窗体，但有一些问题。

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

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

每种解决方案应该使用在什么情况下？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

国产ˉ祖宗 2025-01-02 07:22:56

需要向应用程序添加数据访问层 (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 模板工具等工具可以提供很大帮助。

There are a number of different options available to a developer that needs to add a data access layer (DAL) to their application. I'm going to assume here that when you say "Visual studio can generate code for that", you are referring to Microsoft's Entity Framework (EF), which you can use to generate business objects and repositories from a schema (and vice versa). There are other ways that VS could be used to generate your data access layer (e.g. using T4 templates and code generation). Some of the factors that come into play when considering whether to roll your own data access layer include:

Time. Probably the biggest factor (in my opinion). There are plenty of references available to learn the conventions required to get up and running with an EF data layer in very little time in deed. This is an extremely fast route to take to get data into your application. Past simply loading and saving data from a persistence store, existing frameworks such as EF make it easy to quickly support things like transactions and caching. If write your own DAL, it will probably take longer to get data out of a data store, and it will certainly take longer to test it to the same degree that EF is proven.
Features. You get A LOT of features 'out of the box' with EF. It will take a while to add these to your DAL.
Experience. There are plenty of pitfalls when writing your own DA layer from scratch - why re-invent the wheel? Writing a good DAL from the ground up takes some coding experience to do well (but is a great learning experience and a very satisfying project to work on)
Control. You may prefer to write your own DAL if you prefer to be in control of every aspect of the code. Whilst a framework like EF can be configured in many ways, and will work for many applications, particular simple ones, the more complex requirements of a large application (be it computationally complex or with a particular performance profile) may be better suited to the more tweakable custom DAL. For example, you might not like the SQL generated by EF, or you don't like the way that child models are loaded. There are plenty of open source DALs which provide a solid foundation to build on, making it easy to hook into any aspect of the DAL.
Existence of Legacy Code. In some extreme cases, if you working within an exiting application and you need to meet existing interface requirements, or fit with existing patterns of data loading, you may find it easier to generate your own DA layer. The preferable alternative here would be to write an adapter layer to adapt your DAL to the existing application requirements, thereby decoupling your DA layer from legacy code requirements.

If you do plan to write your own DAL, I'd certainly recommend looking taking a look at code generation options that exist. Plan for your schema to change frequently, and be able to regenerate your custom DAL quickly. Tools like Code Smith, MyGeneration and the T4 templating tools in VS can be a great assistance when writing a DAL from scratch.

回复收藏 0 原文

~没有更多了~