【发布时间】:2011-06-18 15:42:45
【问题描述】:
有这个网络应用程序,它依赖于一种直接从数据库生成的数据访问库(简单的数据对象和关联对象对其执行 CRUD 操作)。
所以来自 Person 表
ID
Forename
Surname
DoBirth
你会得到一个带有字段的生成 Person 类:
ID, Forename, Surname, DoBirth 从他们的 db 列中键入。
还有一个辅助类 PersonPersister
与
Create(Person p)
Update(Person p)
Delete(Person p)
方法。
它还将在数据库上创建必要的 CRUD 存储过程。
当我开始时我对此感到不安,因为除了与 nHibernate 和 MEF 的短暂调情外,我习惯于对我的数据访问层进行手工编码。现在,我所有的担忧似乎都在实现,一年过去了,因为我们正在与更大的开发团队进行另一阶段的开发,并且裂缝已经开始出现。
基本问题是,作为开发人员,我们无法控制生成的内容,也无法对 DAL 进行版本控制。
每次发布时,我们都会花很多时间手动配置应用程序、dal 和数据库以使其正常工作。通常情况下,DAL 是从 dev db 生成的,然后应用于 live db,这当然缺少在开发过程中创建的表/sprocs 等。
在这些时候,我经常发现自己前往 jobserve.com,尽管除了这个问题我更喜欢在这里工作。
我的想法包括修改代码生成器,以便它覆盖显式处理 DAL 的 Visual Studio 项目中的源文件 - 然后这些文件可以在 CVS 中进行跟踪,也可以手动编辑。有没有人对这种策略有任何积极的经验?目前,构建生成的唯一工件是 dll,因此无法查看更改历史记录。
除了使用 ORM(管理层不是粉丝 - 是的,我知道)之外,我们还有哪些选择可以合理化它以让我们自己控制?我们仍然需要自动化元素,但目前我们拥有的数量是不可行的。
我们很幸运在这里订阅了 MSDN,因此我们正在运行带有自动构建的 TFS 2010、最新的 Visual Studio 等,但由于我们开发环境的这一方面,感觉就像我们是落后时代十年或更长时间。
【问题讨论】:
-
对我来说听起来很混乱。我在一个项目中工作,开发人员在提交影响数据库模式的代码时必须更新“发布”SQL 脚本。 (作为发布周期的一部分,该脚本经过审查并应用于客户的数据库)
-
'Churn' 是描述它的一种方式:-o
标签: c# asp.net code-generation data-access-layer data-access