(我是 MVC 的初学者)
我的意思是有一个带有域模型的业务逻辑层和一个带有视图模型的应用程序服务层,控制器只从应用程序服务方法获取视图模型。控制器不包含任何逻辑,MVC 模型是视图模型(来自应用服务层),其中包含仅与显示相关的逻辑。
我在 ASP.NET MVC 上看到的任何教程都侧重于在控制器类中包含逻辑,但我认为通过这种方式(在大型应用程序中)您可以复制业务逻辑,编写冗余代码。
(我是 MVC 的初学者)
我的意思是有一个带有域模型的业务逻辑层和一个带有视图模型的应用程序服务层,控制器只从应用程序服务方法获取视图模型。控制器不包含任何逻辑,MVC 模型是视图模型(来自应用服务层),其中包含仅与显示相关的逻辑。
我在 ASP.NET MVC 上看到的任何教程都侧重于在控制器类中包含逻辑,但我认为通过这种方式(在大型应用程序中)您可以复制业务逻辑,编写冗余代码。
是的,将它们分开是个好主意。我看到它完成的方式是你有你的“业务对象”命名空间,然后是你的“视图模型”命名空间。“查看模型”命名空间中的对象是 MVC 的模型,通常包含常规类型和业务对象实例的混合。
区分域模型和 MVC 模型是否是一种好方法
当然,我总是将我的域模型与我的视图模型分开,因为和你一样,我同意域模型不属于控制器。
ASP.NET MVC 项目中的控制器实际上是视图控制器,因此不应真正包含业务逻辑。使用服务层通常是管理表示/业务层之间通信的最佳方式(就像您似乎正在做的那样)。