Is there any benefit to using Cocoa's version of MVC with .NET?这里有一个图表描述了传统MVC和可可MVC之间的区别： 可可设计模式：模型-视图-控制器设计模式 使用Visual Studio在.NET中以"可可"方式进行操作是否有任何好处？ 如果您觉得更合理，那么没有理由不这样做。请注意，Cocoa框架中的许多内容都是由于高层设计决策而产生的，例如，在子类化过程中偏爱组成和委派。 如果需要，您可以设计类似于Objective-C软件的C#软件，但是没有Cocoa经验的人将不得不向他们解释，因为松耦合的设计对他们来说似乎"很奇怪"。 哦，对了-这种设计的优点包括UI视图和模型类的重用性更高(因为它们彼此之间没有任何知识)，视图类中的代码稍微简单一些，以及更多的"应用程序逻辑"放在单个位置(控制器类)。 .Net开发人员杂志上的一名开发人员一直在撰写有关他的过渡并将.Net与Cocoa进行比较的文章，包括在.Net中使用Cocoa MVC样式。 http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa 使用Cocoa的"中介控制器"(NSController的子类)的主要优点是，它们实现了在模型及其视图之间进行中介所需的大部分标准功能。"免费"包括诸如跟踪视图选择所指示的模型部分以及事务支持(例如，您可以提交或放弃对视图或模型的一组修改)之类的事情。将NSController子类用作模型和视图之间的"胶水"代码，可以使您摆脱开发人员的注意力，专注于"协调控制器"功能-驻留在控制器层中的特定于应用程序的逻辑。 那么，在.Net中使用此模式值得吗？使通用协调控制器正常工作并不是一件容易的事(例如，苹果花了两个版本才能使它正常运行)。像树控制器这样的事情特别棘手。如果仅在一个或几个项目中使用此模式，则可能不值得付出努力。另一方面，我确定社区会喜欢通用控制器框架ala Cocoa的NSController层次结构。 ASP.NET MVC中使用的模式不是" MVC的可可版本"吗？到目前为止，所有示例都指出了通过控制器进行通信的黑白视图和模型，而在V和M之间没有直接交互。我是否理解不正确？ |
