1

我的看法是有也没有。

  1. 它确实将逻辑和数据与 UI 分开,但仍将它们全部塞进一个单点应用程序中。
  2. 这就是为什么我认为它不是真的,因为控制器是业务逻辑,视图是 UI,模型是 DAL。这些现在只是同一个应用程序中的层。

但是层应该是第一个或第二个变种,实际上被称为吗?

有人想加自己的 2 美分吗?

4

6 回答 6

4

MVC 模板项目只是为了帮助您入门 -如果您愿意,并且如果它在您的应用程序中有意义,您可以轻松地将控制器和/或模型移出到单独的项目中。请记住,对于可能具有三个控制器、模型层中的几个额外类以及 EF 或 LINQ 数据模型的小型应用程序,您确实没有足够的文件来证明分离到不同项目的合理性。

于 2009-06-03T00:17:20.923 回答
3

我不认为控制器是业务逻辑。它们是应用程序逻辑,是将业务逻辑(模型)和表示逻辑(视图)联系在一起的粘合剂。

于 2009-06-03T08:59:31.770 回答
2

好吧,我的生日蛋糕有几层,但它仍然是一个大蛋糕……是吗?

于 2009-06-03T00:15:39.210 回答
2

当然可以!

我认为视图和控制器都包含用户界面逻辑......业务逻辑应该在模型中(不仅仅是 DAL)。

作为模型,您可以使用例如CSLA 对象并根据需要添加另外几个物理层(通过配置)。

您必须知道逻辑层和物理层(或层与层)之间存在差异......

lhotka 的网站上有很多关于这个主题的有趣文章!
例如这个这个

于 2009-06-03T08:46:08.053 回答
0

层和层是可互换的。在 n 层的上下文中,您将其称为表示层,但在分层应用程序的上下文中,您将其称为表示层。但实际上它们是同一回事。

对 n 层应用程序和松散耦合的试金石测试将是您是否可以将每一层构建为单独的项目并将它们部署在不同的机器上。

n 层应用的关键区别在于关注点分离 (SoC) 和低耦合。一个真正解耦的应用程序可能是一个只包含纯 HTML 的层。然后另一个包含纯 Javascript 并使用 AJAX 更新 DOM 并与 Web 服务通信。Web 服务包含它自己的一组层。

Web 服务有一个路由引擎,可以将请求路由到不同的控制器。控制器清理和解释请求,验证身份验证和不验证的内容,并调用适当的模型。反过来,模型必须返回 POCO 对象或 DTO 并将它们返回给将它们注入 DOM 的 Javascript。Javascript 可能会修改对象并将它们发送回以持久保存到数据库中。Entity Framework 4.0 对这种n 层场景有很好的支持,尽管它在 SoC 部门中确实有点不足(例如强类型视图),但它对于更多目的来说是实用的。

我相信 MVC Futures 支持一些开箱即用的控制反转 (IoC) 容器,目前如果您想要松散耦合和真正的 n 层场景,您可能需要使用您选择的 IoC 容器。

于 2009-06-03T08:58:40.133 回答
0

“层”通常是指不同的物理服务器,而“层”是指将功能分离为松散耦合的区域。

也就是说,一个 3 层 Web 应用程序:第 1 层)数据库服务器第 2 层)Web 服务器第 3 层)客户端浏览器

3 层 Web 应用程序:第 1 层)UI 层 2)业务逻辑层 3)数据访问

于 2009-06-03T21:07:41.750 回答