Łuk*_*.pl 7 c# linq nhibernate entity-framework entity-framework-4.1
我知道这个问题可能有点危险,但我真的需要一些意见.
我们有一个系统,它是一个网站(将是流行的门户网站,我们使用MVC3),在我来到这里之前,我的其他同事选择了NHibernate作为他们的OR Mapper解决方案,他们开始编写标准查询等. .
现在团队更接近Linq方法,所以我们试图在内置的Linq提供程序中编写查询.事情是......它非常适应 - 字面上你不能写非平凡的查询而且不会得到Not supported exception......
我们认为这是最后一个可能的时刻,将我们的OR Mapper更改为更基于Linq的东西,而且我们因为EF4.1获得了非常友好的Code First选项,我们决定这就是我们需要的.
我需要一些意见的问题是值得花时间从NHibernate迁移到EF4.1 ......该项目将持续至少一年的开发,所以我们有很多工作要做,我们想要以愉快和非令人沮丧的方式做到这一点..
一些事实:
那么..现在..迁移是一个好主意还是坏主意？EF会解决我们的问题吗,它会让我们开心还是这一步只会浪费我们的时间？
问候
Lad*_*nka 12
请注意,您将更好地更换linq支持更糟糕的映射功能,有时甚至更糟糕的性能(继承查询,无查询或命令批处理 ......).现在回到黑板上再想一想.如果您现在不喜欢数据库性能,那么EF很难改善.
我想改变技术有点晚了 - 它会有很高的成本.但无论如何,如果你真的想要这样做,为什么不进行概念验证,你可以在一些高级查询中使用一些非常复杂的映射功能,并尝试在EF代码中先做同样的事情？您可以在简单的控制台应用程序中测试相同的内容,并比较映射体验和查询+性能.
性能目前可能不是问题,但它可能是您未来必须优化的东西,EF将为您提供更少的功能.如果要提高EF解决方案的性能,通常会恢复到本机SQL和存储过程.你认为它有更好的写作查询经验吗？
我不得不同意@Ladislav,EF和LINQ很好,它与NHibernate LINQ相比很有用,但是SQL EF生成有时非常糟糕且不是非常高效,你将被迫将复杂的查询重新编码为视图和SP等. Nhibernate也可以陷入这个陷阱,但是有许多不同的选择是一个好处,因为你可以挑选最适合你的需求.
我想你正在考虑平衡以下几点: -
有点从一个ORM跳到另一个ORM就像从煎锅跳进火里.两个都有他们的甜点都会烧伤你的手指!
| 归档时间： |
|
| 查看次数： |
5231 次 |
| 最近记录： |