将 Cocoa 版本的 MVC 与 .NET 结合使用有什么好处吗？

Question

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

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

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

Answer 1

没有理由 不是 这样做，如果它对你来说更有意义的话。请注意，Cocoa 框架中的许多事情都是由于更高级别的设计决策而产生的，例如偏向于组合和委托而不是子类化。

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

哦，对了 - 该设计的优点包括 UI 视图和模型类具有更高的可重用性（因为它们彼此之间没有任何了解），视图类中的代码稍微简单一些，以及更多的“应用程序逻辑” “在一个地方（控制器类）。

Answer 2

.Net 开发者杂志上的一位开发人员一直在撰写关于他的转变以及将 .Net 与 Cocoa 进行比较的文章，包括在 .Net 中使用 Cocoa MVC 风格

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

Answer 3

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

Answer 4

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

那么，值得在 .Net 中使用这种模式吗？让通用协调控制器正常工作并非易事（例如，苹果公司花了几个版本才使其正常工作）。像树控制器这样的东西特别棘手。如果您仅在一个或几个项目中使用此模式，那么可能不值得付出努力。另一方面，我确信社区会喜欢 Cocoa 的 NSController 层次结构这样的通用控制器框架。