但是每当我想添加/实现新服务和相关的DTO时,我都必须编写很多样板代码.此外,还有相当数量的代码重复,将DTO转换为View Models,然后再返回相关的PEBKAC.随着需求的发展,需要将数据库模式的更改传播到View模型.
对于不同的客户端,我继承了一个.netTiers代码生成项目,这让我感到非常悲痛,直到我修复了基本模板中的一些缺陷,使用MSBuild自动生成代码,并且还使用MSBuild,按摩生成的代码以使其构建没有以前需要的手动调整目录. .netTiers最终产生了许多有用的代码,但是有大量的重复,一堆复杂性,感觉就像用一把大锤去皮猫.
现在我正在寻找另一个MVC3项目,我想避免自己编写所有样板,但我也想避免完整的.netTiers类型代码生成.我没有用EF.我倾向于认为它对于我承担的项目规模而言是一个太大的工具,但如果它可以为我带走一些手动步骤那么这将是一个很大的节省时间. EF的优点是什么？它会为我设计服务层吗？
我正在考虑的另一个选项是LightSpeed,这需要我花一些钱(不是很多),但如果它可以为我生成服务层代码,那将是花钱. LightSpeed是否支持这种类型的代码生成？
显然,随着域模型和数据库模式的发展,需要更新服务以适应这些变化. .netTiers通过生成部分类来实现这一点.这些其他工具如何在不覆盖服务层中的任何自定义逻辑的情况下处理这些更改？
还有哪些其他选择？
更新：感谢所有的反馈,很多积极的选择.有人看过MVC Scaffolding吗？
更新#2：我将继续推行MVCScaffolding选项,为EF Code First生成代码.开箱即用它会产生一个Repository类,然后有点不幸地将它与模型结合在一起,而MVC实际上是View Model而不是Domain Model.对于服务层脚手架的MVCScaffolding项目有一个pull请求,因此将调查该选项.加上用于映射POCO的AutoMapper< - > DTO的.
解决方法
我们仅用于EF代码的过程：
>从我们的数据库构建一个edmx
>安装T4 POCO类生成模板
>生成我们的POCO和上下文类
>删除我们的edmx和T4模板,保留POCO和上下文类
实体框架中的新工具非常棒,因为它们为您提供了多种选择：
型号第一：
> edmx中的模型
>从edmx生成数据库
>从edmx生成POCO类
>(可选)删除edmx,运行Code Only
代码优先：
>写POCO课程
>从POCO类生成数据库
>(可选)从POCO类生成edmx
数据库优先：
>构建数据库
>从数据库生成edmx
>从edmx生成POCO类
>(可选)删除edmx,运行Code Only
附录(14/01/2012)：
Code First Migrations的测试版已经发布.我们还没有调查它,但它看起来很有趣.
> Code-first Migrations – Beta Announcement
> Code-first Migrations – No Magic Walkthrough
> Code-first Migrations – Automatic Migrations
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
