在MVC中编写数据库和业务逻辑的位置？

Question

在我学习和使用Asp.Net MVC应用程序时，我想知道在Business Logic中写Data Access logic和MVC的最佳位置是什么。

我应该在哪里编写DataAccess和Business Logic三层（Model, View and Controller）??

请有人告诉我为此编写代码的正确方法。

场景：我想retrieve all the employees where employee name like 'Mi%'（我有SQL procedure to execute and retrieve the data.）

PS：想知道我应该在哪里创建Business Logic类的实例以及我应该在哪里创建数据访问层类的实例？

提前致谢。

Answer 1

业务逻辑（BL）和数据访问（DAO）应位于不同的层中。模型应该只保留数据而不包含逻辑。控制器应仅从视图接收数据并将其发送到BL层（或从BL发送到视图） 这不是一个严格的规则，但最近使用的方法

Answer 2

业务逻辑应该在模型中。

数据访问可以在以后的控制器调用中自行调用，也可以在控制器通过存储库调用的ORM中自动执行。

在Nerd Dinner中可以找到有关此内容的演练，请查找free download section。

Answer 3

视图是您放置界面代码的地方。

Controller是将视图与模型连接的位置。

该模型存储业务逻辑和可能的数据库访问。 （可以使用一些ORM层）

Answer 4

你可以完全跳过三层思维，然后采用另一种思维方式;

用户行为;将命令或事件发送到后台服务。后台服务，您可以在进程中运行，对于初学者。后台服务再次在内存中发布事件。您创建多个视图，从后台服务订阅事件。每个视图都有一个'上次见过'事件;这是一个整数。每个启动它从“全局日志”中读取所有以后的事件。

视图是丢失的，因为你有来自GUI和后台服务的事件/命令的全局日志，无论如何，他们会在你开始时读取所有错过的事件。

这相当于“做某事，我希望在另一个视图中看到'改变'”。你也有：

交互是指当您从GUI或后台服务中获得单个或多个事件时，您可以让某个参与者（很可能是Saga）执行某些操作，可能需要根据其他事件进行补偿。失败。

另外，我建议您浏览this presentation