1 c# data-access-layer asp.net-mvc-4 .net-4.5
我对MVC 4很陌生,到目前为止我在C#中主要使用Web表单.我理解MVC的模式,路由,调用动作等等.
但是负责从数据库中获取数据的操作呢,例如通过激活存储过程?我看过一些教程,他们在操作中直接连接数据库的逻辑.
但是,我正在考虑采用更集中的方式来实现它.例如,我可以将所有触发存储过程的函数放在一个名为DatabaseCoordinator.cs的单独类中,例如,名为Helpers的文件夹中.然后我可以从控制器中的动作调用它们.
通过这种方式,我将知道我可以在一个类中找到我的所有数据库方法,这是一个非常干净的解决方案,我认为(或至少在Web表单中).但是我想遵循MVC的模式,并且只使用模型,视图和控制器作为模式本身的名称.
那么最佳做法是什么?我应该为此单独创建一个类,还是直接在控制器中或者在其他地方实现逻辑?
您当然应该创建一个单独的存储库类来包含所有数据访问操作.
这里有一个很好的例子:http: //www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/implementing-the-repository-and-unit-of-work-patterns-在安-ASP净MVC应用程序
小智 5
我建议您将数据访问代码放在控制器以外的其他位置.控制器的主要目的是将信息收集在一起以显示在页面上或反过来 - 从回发的页面获取数据并将其提供给负责业务规则和数据访问的代码.
对于大多数MVC项目(哎呀,对于大多数项目来说真的!)我构建了单独的类库项目 - 至少一个用于业务规则和数据访问,尽管我通常会创建这两个独立的项目.分离逻辑的目的实际上是为了更简单的将来维护和可重用性.如果将各个逻辑部分分开,如果您的逻辑或数据库需要更改,您可以轻松地将它们交换出来,或者您可以轻松地从新类型的用户界面中使用业务规则和数据; 例如,如果您决定在Web系统之外将项目实现为Windows窗体应用程序,则(理论上)您可以重用业务逻辑和数据访问逻辑库,并仅重建用户层.但是,如果你将逻辑构建到控制器中,你真的可以'
所以,简单地说,绝对保持99%的逻辑和数据访问权限.只将您必须放入控制器中的内容,其余内容放在单独的类中,或者在适当的位置放在单独的类库中.
祝好运!
| 归档时间: |
|
| 查看次数: |
10805 次 |
| 最近记录: |