c# - 现代化 'Hand Rolled' 数据访问库

Question

有这个 Web 应用程序，它依赖于一种直接从数据库生成的数据访问库(简单的数据对象和关联对象以对其执行 CRUD 操作)。

所以来自 Person 表

ID<br/>
Forename<br/>
Surname<br/>
DoBirth

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

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

还有一个辅助类 PersonPersister

与

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

方法。

它还会在数据库上创建必要的 CRUD 存储过程。

刚开始时我对此感到不安，因为除了与 nHibernate 和 MEF 的短暂调情之外，我习惯于对数据访问层进行手动编码。我所有的担忧现在似乎都变成了现实，一年过去了，因为我们正在与更大的开发团队进行另一个开发阶段，并且裂缝已经开始出现。

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

每次我们发布版本时，我们都会花很多时间手动配置应用程序、dal 和数据库以使其正常运行。通常情况下，DAL 是从开发数据库生成的，然后应用于实时数据库，这当然缺少在开发过程中创建的表/存储过程等。

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

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

除了使用 ORM(管理层不喜欢 - 是的，我知道)之外，我们还有哪些选择可以合理化，让我们自己控制？我们仍然需要自动化的元素，但我们目前拥有的数量是行不通的。

我们很幸运在这里订阅了 MSDN，所以我们运行的是带有自动构建的 TFS 2010、最新的 Visual Studio 等，但由于我们开发环境的这一方面，感觉我们是落后于时代十年或更长时间。

Answer 1

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