MVC(模型-视图-控制器)范式是一种更好的开发方式还是仅仅是一种新的复杂范式?

你的比较基础是什么?如果您习惯了Perl/CGI,那么它可能有点复杂!

在Web术语中,MVC(或Django首选的模型模板视图,与原来的Smalltalk MVC分离)倾向于允许在应用程序中更好地分离关注点。在我(和许多其他人)的经验中,这会导致更易于维护的可扩展、测试良好的代码。

对今后的一些建议。在不了解你的背景的情况下,很难提出具体的建议,而且学习也可能是一件很私人的事情:

• 山姆·鲁比出了一本新书。有各种各样的屏幕投射。
• Django——我也建议这样做,因为这两个Web框架与我使用的框架之间的摩擦最小。

抱歉,我已经离开MS平台几年了,所以我不能在ASP.NET上提供任何建议。

MVC并不是什么新鲜事。它可以追溯到1979年( reference ,所以它已经足够大了,可以喝了。

一般来说,MVC 军队 封装在您身上的一种形式;也就是说,您的视图在很大程度上需要独立于您的模型。一旦你习惯了它,你就会发现它是有用的;也就是说,对于你个人的需要,其他的范例可能更合适。MVC不是万能的,但它是一种看待问题的有用方法。

对我们所有人来说,改变是困难的。在DOS时代,我们使用MTF菜单表格模式。

MVC已经存在了很长一段时间了,而且在互联网编程中使用的所有主要语言都有其特色。

一旦你使用MVC一段时间,你可能就不想回去了。它提供了代码分离和重用。我使用了RoR、Django和ASP.NET MVC,MVC模式使我得以开发。

我鼓励你坚持下去!买本书或找个导师。

嗯,它当然很受欢迎。如果你在做ROR,不要与范式抗争,跟着它走,这就是ROR的全部意义。

如果你处在一个定义你的范式的位置上,事实上,MVC倾向于仅仅是mV。根据模式的一些倡导者所说,控制器更多的是用于多个视图的情况,而在给定的项目中,这几乎总是不适用的(尽管最终在企业内的不同环境中查看数据可能会非常不同)。但是,根据GUI的不同,一个单独的控制器可以帮助代码的可测试性(如果控制器充当测试中的类,并且GUI组件只以尽可能小的方式点击测试中的方法)。

MVC起源于smalltalk人群,后者最近进入了一个变形模式(对象通过一个内部类显示自己,该类子类划分了相关的GUI组件)。当然,这不是一个很难完成HTML工作的方法,因为HTML不能有效地提供给设计者。

就个人而言,如果我真的从零开始,我更喜欢将视图和数据绑定放入表示类中的表示模式(我见过它叫这个,但现在找不到引用)。如果整个屏幕的表示是由数据部分的不同表示组成的,那么模式的威力就来了。在简单乏味的商业应用程序(我倾向于写的那种)中,数据位(比如地址)往往会显示在许多屏幕上,因此能够将GUI表示组件分块并重用是很有帮助的。

但是现在,如果你需要从头开始做的话,你真的需要仔细考虑,至少在旧的无聊的数据显示和操作应用程序中是这样。外面有很多东西,如果你使用一个工具,你应该使用它的模式。对抗这种工具是适得其反的。

MVC既不是新的,也不是特别复杂。MVC是一个已经存在很长时间的标准范例。我记得10年前在我的软件工程课上,它是一个突出的模式。一旦您理解了MVC,它就为您的项目提供了一个非常干净、可测试的实现。它当然不同于WebForms——而了解WebForms实际上可能是学习ASP.NET MVC的障碍——但我不打算回去。我只希望ASP.NET MVC变得越来越好,因为我们看到为它构建的控件与WebForms的控件类型相同。

因为它是新的,所以感觉很激烈。其实没那么糟。

查看真实的应用程序可能会有所帮助。

退房 http://www.nerddinner.com/ 作为一个很好的例子,以及 Professional ASP.NET MVC 1.0 包含代码的书。

一个更具系数的/分层的设计在开始的时候总是很难让你的头脑清醒过来——只有在这种情况发生的时候才会有回报。优点是,现在您已经清楚地定义了放置什么的位置;虽然一开始被迫坚持预先确定的关注点分离看起来很麻烦,但是代码结构的可预测性使得以后维护起来容易得多。