Codesmith是一个可行的ORM工具(或者我应该坚持使用真正的ORM)

我正在购买ORM工具.我对购买CodeSmith(目前大幅折扣)和ORM工具感到痛苦.

LINQ to SQL不在我的列表中; SubSonic 2.x不在列表中(我不想投资那个知道SubSonic 3.0即将到来的死胡同.NHibernate看起来像LLBLGEN一样有点过分.我只是简单地评估了EF但是没有快速得到一个温暖而模糊的感觉.

我疯狂地认为CodeSmith是现成ORM的理性替代品吗？CodeSmith会以其他方式为自己买单吗？

请注意,我与任何供应商没有任何关系,这不是一个便宜的镜头问题只是为了产生产品噪音!我正在寻找关于CodeSmith作为ORM工具(提供或社区可用)模板的诚实建议和意见.

事实上,hibernate是一个很好的ORM工具.但它停在那里!

代码史密斯功能不仅仅是关系映射人员!我使用代码smith生成一些UI表单,业务层(模板),数据访问层,模式等.但是要使用代码史密斯,您可能需要良好的系统设计经验或使用我不喜欢使用的模板,但我喜欢这样的例子.

Code smith方法有一个特殊的缺点; 您必须首先考虑数据库实现来设计系统.如今,在对象分析方法中,人们在任何数据库实现之前就成功实现了业务逻辑和实体 - 他们忘记了这一点.

决定很难; 我一直在阅读重要的名字,比如Scott W. Ambler,Kent beck,Robert C. Martin以及来自The Pragmatic Programmers系列的人们,他们推荐使用ORM Tool来加速开发.他们说ORM工具开发人员关注所有数据库问题(池,连接,数据库供应商细节等).因此,当我们必须设计数据访问层时,我们也必须考虑所有这些方面.

我相信这些ORM工具带来了负担过重.我还不知道这些工具在低预算项目中会如何表现(我的意思是不是很好的托管服务器或任何类型的共享资源).我见过没有经验的开发人员在尝试传播他们心爱的工具时没有考虑到这一点.但是在java项目中,hibernate已经是一种广为人知的工具.我毫不怀疑使用这项技术已经提供了很棒的项目,但我看到有人和Java开发人员可能需要教我们(.net开发人员)如何构建出色的解决方案.(对不起,我们必须承认.)

我唯一建议的是考虑你的背景.你在做一个新系统吗？你需要在模式中工作吗？你有没有尝试过这样的代码生成器和ORM工具？

我更喜欢代码史密斯,因为我一次生成整个解决方案,而不仅仅是数据访问层.代码生成非常重要,微软已经在visual studio.net 2008中模仿了代码smith方法等等.

祝好运

Code Smith不是ORM,它只是一个代码生成器IDE.

您可以使用基于数据库的代码smith生成DAL,但这会破坏(使用)ORM的目的,其基本上是动态生成DAL,因此您不必编写代码.

如果你真的想要比较两者,那么也许你可能会使用代码史密斯获得一些好处,因为你可以绝对控制生成的代码,但我不确定这些好处会超过可能转向的缺点花费数月时间编写代码smith模板以生成基于数据库的DAL.

然后你必须考虑当你对数据库进行更改时会发生什么,你很可能每次都要运行代码smith并构建.一个好的ORM将允许您在模式中配置数据库更改,然后它将动态生成,因此您不必担心(尽可能多)关于对数据库进行更改.

NHibernate是要走的路.这是一个企业级的ORM.使用FluentNHibernate库中基于约定的自动配置,如果您坚持使用单一约定(您可以指定约定,或者存在默认值),则配置非常简单.

使用NHibernate,您的域对象是纯C#对象.没有奇怪的基类.每次您决定进行更改时,都不需要刷新代码生成的文件.