我正在用MVC重写一个Web应用程序,我试图不挂在体系结构上,但是随后,MVC有一些我想坚持的模式
我的应用程序具有显示从数据库检索到的数据的视图。
通常,我将编写如下的控制器动作
public ActionResult Index()
{
var model = new IndexModel();
model = DbHelper.GetData(); // business layer
return View(model);
}
但是我一直在读一些文章,说应该在模型中进行数据访问,这样会更好吗?
public ActionResult Index()
{
var model = new IndexModel();
return View(model);
}
和IndexModel:
public class IndexModel
{
public string EmailAddress { get; set;}
public IndexModel()
{
// Fetch data in here...
EmailAddress = DbHelper.GetEmail(); // for example
}
}
那么,控制器应该包括提取数据的逻辑,还是模型应该处理它?许多MSDN示例显示了填充模型的控制器,但这似乎打破了MVC的层次
答案 0 :(得分:1)
问题是基于某种观点的。但是考虑以下想法可能会有所帮助:
模型
查看
Model
,不要直接调用业务逻辑类。控制器
业务逻辑
数据访问
一般注意事项
答案 1 :(得分:0)
MVC(模型视图控制器)是控制ASP.NET MVC应用程序体系结构的更广泛的设计模式,但它不是给定应用程序应遵循的唯一模式。最终目标是拥有简洁的代码,松散耦合的工件,并专注于代码可重用性。
通常,我的项目架构方法是为数据访问层(通常是类库项目)提供一个单独的项目,为 Business-Layer(实现业务级别的决策)提供一个项目(也是类库项目)和 ASP.NET MVC项目(作为 Presentation-Layer 项目)。 Business-Layer项目具有Data-Access项目的dll引用,Presentation-Layer项目(ASP.NET MVC Project)应具有Data-Access和Business-Layer项目的引用。
现在我使用依赖注入方法向其构造函数中的控制器提供数据访问依赖
private IDbHelper dbHelper;
public HomeController(IDbHelper _dbHelper)
{
dbHelper=_dbHelper;
}
因此,应通过依赖关系注入程序(例如Ninject)使db-access类可用,并且各个操作方法不必担心如何创建对象。现在,您的操作方法应像这样简单地调用dbHelper类
public ActionResult Index()
{
return View(dbHelper.GetData());
}
还请注意,除了使用 Models ,您的应用程序还需要创建 View-Models(VM)(从数据库返回并由业务层修改的模型以满足业务需求具体需求)。
因此,简而言之,一个好的项目是几种不同模式和体系结构样式的组合,它们的实施是为了使代码可重复使用,简洁,简洁并且易于测试。
谢谢。
答案 2 :(得分:0)
考虑使用依赖注入,特别是如果您要进行大量的单元测试(例如,使用Moq)时。 Obaid(在上面发帖的用户)发布了有关此信息。
有关更多信息,请参见以下参考资料:
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.2
注意:如以上参考中所示,您将需要在Startup类中配置服务(或选择为MVC配置所有服务的任何类型)。