代码之家 › 专栏 › 技术社区 › Harishbb

DAL层:EF4.0或带存储过程的普通数据访问层

entity-framework-4 data-access-layer silverlight-4.0 ado.net

1

Harishbb · 技术社区 · 15 年前

应用:

我正在研究一个将用作产品的大中型应用程序,我们需要决定我们的DAL层。应用程序UI位于Silverlight中,DAL层将位于服务层之后。我们也在推进域模型,因此我们的DB表和域类的结构不同。所以像数据映射器和存储库这样的模式肯定会出现在图片中。

我需要优先考虑以下因素来设计DAL层

发展速度高于平均水平
维护
技术的未来支持和稳定性
性能

局限性:

1)由于我们需要严格与微软合作,因此我们不能使用NHibernate或任何其他ORM,EF4.0除外。

2)我们可以使用任何代码生成工具(应该是开源的或非常便宜的),但是它应该只在.NET中生成代码,所以在每个副本的基础上不会有任何许可问题。

问题

我读了很多关于EF4.0的文章,一开始看起来它还缺少NHibernate的特性,但比EF1.0要好得多。

所以,你们觉得我们应该继续使用EF4.0还是应该坚持使用ADO.NET并使用任何代码生成工具,如code smith或其他你认为最好的工具?

此外,我还需要回答一些问题,例如,如果将来我们在某些功能方面坚持使用EF4.0,或者我们有严重的性能问题,那么将应用程序从EF4.0移植到ADO.NET需要多长时间。
在相反的情况下,如果我们继续选择ADO.NET,那么什么时候才能切换到EF4.0

最后..当我浏览这篇文章时,我发现只有代码的方法(使用poco类)似乎最适合我们的需求,因为从一种技术到另一种技术的转换非常容易。

请分享您对这一点的看法,并对上述问题进行指导。

2 回复 | 直到 15 年前

1

2

marc_s 15 年前

使用EF4可以帮助您很多人工编码或代码生成。这似乎证明了使用它的合理性——最好的代码和唯一保证没有错误的代码是您不需要编写的代码。

EF4和NHibernate等是非常强大的工具,可以处理最苛刻和最复杂的业务需求——比如数据库表中的继承等等。不过,它们确实增加了一些开销——而且它们并不总是容易学习和学习的。

所以我的问题是:为什么不使用 LINQtoSQL ?如果您只需要SQL Server作为后端,那么如果您的映射几乎总是域模型中表和类之间的1:1映射,那么这可能比使用EF4或NHibernate容易得多。

LINQtoSQL肯定比EF4更容易、更快——它只是数据库顶部的一个非常薄的层。它比学习nhibernate容易得多——学习它不需要混乱的映射语法,您可以通过可视化设计器获得支持。它非常简单,您甚至可以进入其中并使用T4模板(参见Damien Guard的 Linq-to-SQL templates )

即使在.NET 4/Vs2010中,linq-to-sql也得到了100%的支持,所以很有可能它仍然在VS2012中出现(或者下一个将被称为什么)。所以所有关于世界末日的预言都被夸大了——我一秒钟也不担心它的未来证明。

更新: linq to sql和ef之间的一些性能比较:

一般来说,linq-to-sql在查询性能上似乎有优势,但ef在更新方面似乎做得更好。

2

1

TomTom 15 年前

从存储过程绑定的DAL是正常的这一点上,您可以从何处得到这种想法?我个人像15年前那样对他们说了再见,然后对市场上任何ORM这样的系统说了再见(hing:实体框架相对于NHibernate这样的东西来说是不好的)。我个人总是非常有趣,除了“粉丝”女士之外,其他人都是新的。

即使考虑到实体框架的局限性,它也远远优于您可以手动使用存储过程所能想到的任何东西。

1:通常大约40%到60%的代码处理数据库交互。这可以通过任何一个非愚蠢的ORM来消除--进行数学运算。

2:见1。

3:好问题。可悲的是,微软在数据访问领域做了非常愚蠢的事情。

4:很可能和你的手写的一样——在5%以内。遗憾的是,您的贫血ORM(实体框架)没有实现任何真正有趣的功能(缓存等),因此Hugh的收益不是自动实现的。