假设我们正在为中小型企业开发电子商务Web应用程序。我们进一步假定业务可能会随着时间的推移而扩大。换句话说，产品线通常会增长。
到目前为止，我已经在sqlHelper类的帮助下开发了使用ADO.NET和存储过程的n层解决方案。对于更大的应用程序，我使用了Enterprise Library(2.0)。
我想转向基于ORM的方法，并开始学习LINQ以及从ASP.NET Web窗体切换到ASP.NET MVC。我不想用LINQ to sql。问题不在于是否需要ORM，而是实体框架ORM是否对这样的项目过度使用。我不介意学习曲线，如果这是有必要的手头的任务。
关于“过度杀戮”，我想知道：
> EF比手动正确技能编码查询的人快
> EF导致不必要的代码膨胀
> EF不必要地屏蔽了他们查询的代码级细节
> LINQ-to-Entities适用于这种规模的项目
事实上，如果有人认为ORM对于这样的项目来说太过分了，我想听到原因。
解决方法
EF对于网络应用程序来说不过分。
我不同意你引用的文章中所说的很多内容。我同意开发人员应该使用sql的体面技能BUT ORMS做得很好，让开发人员的工作更快地完成。
ORMS的速度 – 他们正在得到
一切都好他们允许你
调用SP或修改查询
在必要时获得最大速度。还有很好的Profilers在那里监测ORM性能，如EFProf。
>减少编码过程 –
真！！！一旦学会了，它加速了它
向上。
开发人员需要知道sql – 我同意。
但是，ORMS尤其是LINQ
语法通常允许开发者写更多
复杂的sql比他们会
他们自己的。
> Devs写高效的查询已经 – 非常友好!!!!只要问DBA他/她的想法！我碰巧认为我也是，但其他人也是如此。看到问题。