asp.net-mvc – ASP.net MVC控制器 – 构造函数的用法

发布时间：2020-12-15 19:01:30 所属栏目：asp.Net 来源：网络整理

导读：我在一个ASP.net MVC应用程序，我有一个问题使用构造函数为我的控制器。我使用Entity框架和linq到Entities我的所有数据事务。我需要访问我的实体模型几乎所有的控制器操作。当我第一次开始写应用程序时，我在每个Action方法的开始创建一个实体对象，执行任

我在一个ASP.net MVC应用程序，我有一个问题使用构造函数为我的控制器。

我使用Entity框架和linq到Entities我的所有数据事务。我需要访问我的实体模型几乎所有的控制器操作。当我第一次开始写应用程序时，我在每个Action方法的开始创建一个实体对象，执行任何我需要的工作，然后返回我的结果。

我意识到，我为每个动作方法反复创建相同的对象，所以我为Entity对象创建了一个私有成员变量，并开始在每个控制器的构造函数中实例化它。现在每个方法只引用私有成员变量来做它的工作。

我仍然怀疑自己在哪条路上是对的。我想知道A.)哪个方法是最合适的？ B.)在构造函数方法中，这些对象生存多久了？ C.)有构造函数方法的性能/完整性问题吗？

谢谢

你在问正确的问题。

A.在每个action方法中创建这个依赖关系是绝对不合适的。 MVC的主要特征之一是分离关注的能力。通过加载这些依赖关系的控制器，您将使控制器变厚。这些应该注入控制器。有依赖注入(DI)的各种选项。通常这些类型的对象可以被注入到构造函数中，也可以注入到属性中。我喜欢的是构造函数注入。

这些对象的生命周期将由垃圾收集器确定。 GC不是确定性的。因此，如果你有对象连接到资源受限服务(数据库连接)，那么你可能需要确保你关闭这些连接你自己(而不是依赖于dispose)。很多时候，“生命周期”的关注被分离为控制反转(IOC)容器。有很多。我的偏好是Ninject。

C.实例化成本可能很小。数据库事务成本是您可能想要集中注意力的地方。有一个概念叫做“工作单元”，你可能想看看。基本上，数据库可以处理大于仅一个保存/更新操作的事务。增加事务大小可以导致更好的数据库性能。

希望让你开始。

鲍勃

（编辑：李大同）

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