.net - 将 Cocoa 的 MVC 版本与 .NET 一起使用有什么好处吗？

Question

这里有一张图描述了传统 MVC 和 Cocoa MVC 之间的区别：

Cocoa 设计模式：模型-视图-控制器设计模式

使用 Visual Studio 在 .NET 中以“Cocoa”方式进行操作有什么好处吗？

Answer 1

如果它对您更有意义，那么没有理由不这样做。请注意，Cocoa 框架中的许多事情都是由于更高级别的设计决策而导致的，例如，优先组合和委托而不是子类化。

如果您愿意，您可以设计看起来像 Objective-C 软件的 C# 软件，但没有 Cocoa 经验的人必须向他们解释，因为松散耦合的设计对他们来说只是“奇怪”。

哦，对了——这种设计的优点包括 UI 视图和模型类的更高的可重用性（因为它们不会相互了解），视图类中的代码稍微简单一些，以及更多的“应用程序逻辑” " 在一个地方（控制器类）。

Answer 2

.Net developer's Journal 上的一位开发人员一直在撰写有关他的过渡并将 .Net 与 Cocoa 进行比较的文章，包括在 .Net 中使用 Cocoa MVC 样式

http://dotnetaddict.dotnetdevelopersjournal.com/tags/?/cocoa

Answer 3

“可可版本的 MVC”不是 ASP.NET MVC 中使用的模式吗？到目前为止，所有示例都指向通过控制器进行黑白视图和模型的通信，而 V 和 M 之间没有直接交互。我是否理解错误？

Answer 4

使用 Cocoa 的“中介控制器”（NSController 的子类）的主要优点是它们实现了在模型和视图之间进行中介所需的大部分标准功能。诸如跟踪视图选择所指示的模型部分和事务支持（例如，以便您可以提交或放弃对视图或模型的一组修改）之类的东西是“免费”的。使用 NSController 子类作为模型和视图之间的“胶水”代码，作为开发人员，您可以将精力集中在“协调控制器”功能上——驻留在控制器层中的特定于应用程序的逻辑。

那么，是否值得在 .Net 中使用这种模式？让一个通用的协调控制器正常工作并非易事（例如，Apple 需要发布几个版本才能让它正常工作）。树控制器之类的东西特别棘手。如果您只在一个或几个项目中使用此模式，则可能不值得付出努力。另一方面，我相信社区会喜欢一个通用的控制器框架，比如 Cocoa 的 NSController 层次结构。