应将存储过程业务逻辑放置在MVC中哪里？

鉴于不同的消息来源给出了不同的建议，我正在寻找一些经验和解释。我对MVC完全陌生。我知道这个问题之前已经被问到过，但我不是（目前）使用EF或Linq。应将存储过程业务逻辑放置在MVC中哪里？

我有一个SQL数据库与许多存储过程。以前与webforms一起使用时，业务层包含用于调用过程并将DataSet返回到页面的辅助方法。重要的部分是程序经常询问大约20张表格; 页面不只是反映数据库结构完全相同（如我在大多数MVC教程见）：

SQL database <--> stored procedures <--> business layer <--> web forms

我想在这里采取的最佳方法，开始在右边的基础和学习正常，但欣赏有可能没有正确的答案。因此，如果你发布，你能否提供一些关于“为什么”的解释？

如果存储过程的逻辑（的SqlCommand /商业方法等），型号或 Controller中去？

One post advises neither，但保留业务层。 Another expert建议，

[型号/实体]不应该有一个什么样的从数据库

如果业务层被保留，到哪里都是调用的方法回来以外的任何附加的方法来自（如模型或控制器）？
如果上面的答案是“都不是”，那么这是否意味着模型部分将不使用？

，几乎感觉，事情并没有正在这似乎是发生了什么this tutorial做正确，但是。

我应该在模型层插入实体框架来调用业务层吗？

这感觉像是矫枉过正，增加了所有额外的逻辑。

来源

2014-08-29 EvilDr

正如所有的东西，这个取决于你要多少精力投入在有很大的文章。适当的层和分离关注/单元测试对于单页小应用程序来说可能是过度的。我已经回答了这个问题，假设你想以“正确”的方式做事，即使它是一个小例子项目 – Liath 2014-08-29 09:41:29

您的控制器应该收集构建用户当前正在查看的页面所需的信息。而已。

控制器应引用业务逻辑层中的类。

例如，这里是你的控制器。它所做的只是转换http请求并调用业务逻辑。

public class MyController : Controller 
{ 
    private IMyBusinessLogic _businessLogic; 
    public MyController(IMyBusinessLogic businessLogic) 
    { 
     _businessLogic = businessLogic; 
    } 

    [HttpPost] 
    public ActionResult UpdateAllRecords() 
    { 
     _businessLogic.UpdateAllRecords(); 
     return Json(new Success()); 
    } 
}

和你的业务逻辑类

public class MyBusinessLogic : IMyBusinessLogic 
{ 
    public void UpdateAllRecords() 
    { 
    // call SP here 
    using(SqlConnection conn = new... 
    } 
}

有许多的优势，这一点：

你的业务逻辑是完全从你的用户界面分离，没有数据库的代码在你的表示层。这意味着您的控制器可以专注于它的工作，并且代码不会受到污染。
您可以测试控制器，看看当你的业务逻辑成功会发生什么，抛出异常等

对于你应该考虑创建一个数据访问层额外的奖励积分。

public void DataAccess : IDataAccess 
{ 
    public void RunStoredProcedure(string spName) 
    { 
    } 
}

现在您可以测试您的BLL正在调用并正确处理您的SP结果！

扩展以下评论质疑模型： 理想情况下，您的模型应该没有任何逻辑。它应该只是表示构建页面所需的数据。您加载的对象代表系统中的实体，模型代表显示在页面上的数据。这通常要轻得多，并且可能包含额外的信息（例如他们的地址），这些信息不在主要实体上，而是显示在页面上。

例如

public class Person 
{ 
    public int PersonID {get;set;} 
    public string Firstname {get;set;} 
    public string Lastname {get;set;} 
    public Address Address {get;set;} 
}

模型只包含要显示的信息：

public class PersonSummaryModel 
{ 
    public int PersonID {get;set;} 
    public string FullName {get;set;} 
}

你再传给你的模型视图中显示它（也许在FullNames的列表这个案例）。很多人使用mapper类来转换这两者，有些人在控制器中进行转换。

例如

public class PersonMapper 
{ 
    public PersonSummaryModel Map(Person person) 
    { 
    return new PersonSummaryModel 
    { 
     PersonID = person.PersonID, 
     FullName = string.Concat(person.Firstname, " ", person.Lastname) 
    }; 
    } 
}

您也可以使用一些自动化的解决方案，在AutoMapper这样做这一步你。

来源

2014-08-29 08:01:45 Liath

谢谢@Liath。我需要将一个对象返回给控制器（类型为）。我把它放在一个Model中，但是你说它实际上应该在通过BL/Controller引用的DAL中？这实际上意味着应用程序中的Model层几乎没有使用（除了登录模型）。这听起来很正常吗？ – EvilDr 2014-08-29 09:22:05

@EvilDr我已经扩展我的答案来讨论模型太 – Liath 2014-08-29 09:29:39

@EvilDr但是，从业务逻辑/数据访问加载您的实体，并让您的控制器调整它们以在页面上显示它们。这可能看起来像很多类，但是当项目开始增长并且你想测试东西时，它使生活变得更容易 – Liath 2014-08-29 09:33:11

您的控制器应该只涉及编排视图构建。创建一个名为“数据访问层”或不太通用的单独的类库，并创建一个处理调用存储过程的类，从结果创建对象等。关于如何处理这个对象有许多意见，但也许是最

View 
| 
Controller 
| 
Business Logic 
| 
Data Access Layer 
|--- SQL (Stored procs) 
     -Tables 
     -Views 
     -etc. 
|--- Alternate data sources 
     -Web services 
     -Text/XML files 
     -and son on.

，如果你觉得自己的学习层次和最佳途径 MSDN这个链接 MSDN

来源

2014-08-29 08:14:27

应将存储过程业务逻辑放置在MVC中哪里？

回答

相关问题