现代化“手卷”数据访问库

Question

这个Web应用程序依赖于一种数据访问库（简单数据对象和相关对象来对它们执行CRUD操作），它直接从数据库生成。

所以来自人员表

ID
Forename
Surname
DoBirth

你会得到一个带有字段的生成的Person类：

ID, Forename, Surname, DoBirth从他们的数据库列中输入。

辅助类PersonPersister

带

Create(Person p)  
Update(Person p)  
Delete(Person p)  

方法

它还将在数据库上创建必要的CRUD sprocs。

当我开始时，我对此感到不安，除了与nHibernate和MEF的短暂调情之外，我习惯于手工编码我的dataaccess图层。我现在所有的担忧似乎都在实现，一年之后我们正在与更大的开发团队进行另一个开发阶段，并且已经开始出现裂缝。

基本问题是，作为开发人员，我们无法控制生成的内容，也无法对DAL进行版本控制。

每次我们发布时，我们都会花时间手动配置app，dal和databse以使其正常工作。通常情况下，DAL是从dev db生成的，然后应用于实时数据库，当然缺少在开发期间创建的表/ sprocs等。

在这些时候，我经常发现自己正在前往jobserve.com，尽管这个问题除了我喜欢在这里工作。

我曾经有过的想法包括修改代码生成器，因此它会在显式的DAL处理Visual Studio项目中覆盖源文件 - 这些可以在CVS中跟踪，也可以手动编辑。有没有人对这种策略有任何积极的体验？目前，构建生成的唯一工件是dll，因此无法查看更改历史记录。

除了使用ORM（管理不是粉丝 - 是的，我知道）我们有什么选择合理化这个以给自己控制？我们仍然需要一个自动化元素，但我们目前的数量是不可行的。

我们很幸运在这里拥有MSDN订阅，所以我们正在运行TFS 2010，包括自动构建，最新的Visual Studio等等。但是由于我们开发环境的这个方面，感觉我们是一个十年或更久的时间。

Answer 1

这让我觉得你的部署策略更多的是问题，而不是开发策略。无论您使用ORM还是当前工具，它都将从dev数据库生成（如果您使用自动生成）实体。您的部署需要确保对应用程序的所有更改通过您的QA传播到您的生产系统，无论是应用程序，数据库还是其他依赖项。

Answer 2

维护所有存储过程的数据库项目怎么样......

赞成

1. DB的版本控制
2. 轻松部署..您只需要 指定它去哪个数据库 只需点击一下，你就可以部署它......
3. 你确切知道发生了什么变化 引入新班级的结果
4. 所有数据库代码都随之存在 其他代码，可从 一个IDE让它如此之多 更容易一次发送更改..

缺点

1. 您可能需要投入时间 迁移你的礼物 创建存储的基础设施 触发，创造的东​​西 存储过程脚本文件...基本上 create / update / delete中的所有代码 你提到的必须是 再写一次。

以及更多的职业和缺点，你将更好地判断......

如果您考虑使用此选项，则必须查看以下链接

1. Beginner's tutorial
2. Sample Project

Answer 3

我以前使用过代码生成工具，并使用它们生成模板代码，该代码作为Visual Studio项目的一部分包含在内，然后手动修改以满足要求。这意味着代码生成只是节省时间的一步，源代码完全受版本控制。

这听起来像是一个很好的第一种方法，你可以做你所说的文件覆盖，然后你会获得版本控制和适当的QA发布周期的明显好处。

Answer 4

这里有两个问题 - 您的DAL和部署策略。

要解决部署问题，您应该查看Fluent Migrations

我最近为具有类似问题的客户端实现了它，现在他们可以部署应用程序，知道数据库将在必要时自动升级/同步（这是一个可选功能）。

您可以使用流畅的API，嵌入式SQL脚本，内联SQL - 任何适合您的方法。您还可以非常轻松地将迁移器包含在自动构建过程中。

This article揭示了一家公司的经验，并提供了一些代码示例，说明如何将升级过程挂钩到应用程序启动。