asp.net – 用于Web应用程序的实体框架过度杀毒？

发布时间：2020-12-16 00:31:02 所属栏目：asp.Net 来源：网络整理

导读：假设我们正在为中小型企业开发电子商务Web应用程序。我们进一步假定业务可能会随着时间的推移而扩大。换句话说，产品线通常会增长。到目前为止，我已经在SqlHelper类的帮助下开发了使用ADO.NET和存储过程的n层解决方案。对于更大的应用程序，我使用了Enterp

假设我们正在为中小型企业开发电子商务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他/她的想法！我碰巧认为我也是，但其他人也是如此。看到问题。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!