V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
darktiny
V2EX  ›  程序员

MVC强制性拆分真的必要么?

  •  
  •   darktiny · 2011-06-23 21:36:34 +08:00 · 4997 次点击
    这是一个创建于 4906 天前的主题,其中的信息可能已经有所发展或是发生改变。
    做课程设计时,老师要求把程序按MVC进行拆分。想问下前辈们,这样做真的必要吗?
    12 条回复    1970-01-01 08:00:00 +08:00
    yyfearth
        1
    yyfearth  
       2011-06-23 21:56:03 +08:00
    既然是学习嘛,按照标准来可以加强理解,领悟其中的道理
    实际应用的话,分不分我觉得是根据需求来把握的;
    可是如果学的时候就不好好学,弄得4不像的,应用的时候估计也就没法把握了。
    kongruxi
        2
    kongruxi  
       2011-06-23 22:09:56 +08:00
    我看不懂,什么叫:把程序按MVC进行拆分

    是你原来的程序把所有东西都混在一起了?
    darasion
        3
    darasion  
       2011-06-23 22:10:05 +08:00
    人多开发的时候,有必要,据说,非常有。

    一个人开发的时候,那就随便啦
    darktiny
        4
    darktiny  
    OP
       2011-06-23 22:24:21 +08:00
    @kongruxi 老师给了一个C程序要求用C++重新实现
    kongruxi
        5
    kongruxi  
       2011-06-23 22:40:13 +08:00
    @darktiny 原来这样。我觉得这样做还是有必要的,毕竟MVC是前人实践得出的经验
    reus
        6
    reus  
       2011-06-23 23:03:12 +08:00
    做网站或者桌面程序这是很自然的做法啊
    yelusiku
        7
    yelusiku  
       2011-06-23 23:04:46 +08:00
    必要。除非写的是玩具程序,不然数据和呈现必须分离。
    很多时候数据和呈现各自都可能会发生比较大的变化,这在最初设计程序的时候不一定能够预见。
    darktiny
        8
    darktiny  
    OP
       2011-06-23 23:25:50 +08:00
    @yelusiku @reus 谢谢,有没有MC结合或者VC结合这样来实现的,感觉有时候要拆分还是很牵强
    rightgenius
        9
    rightgenius  
       2011-06-23 23:49:23 +08:00
    MVC可以很灵活,实现的时候可以看情况来嘛。当然可以把两层融合一下,甚至在网站的框架中还可以分的更细。只是一个概念,不是一个标准。
    est
        10
    est  
       2011-06-24 00:26:02 +08:00
    LZ莫非是传说中的糙快猛党?
    Kymair
        11
    Kymair  
       2011-06-24 00:47:52 +08:00
    我的想法是,只在你真正了解了一个“传统”或“模式”之后,再去想着打破它
    darktiny
        12
    darktiny  
    OP
       2011-06-24 01:42:26 +08:00
    @est 不是,一直以来用的都是MVC
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1480 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 23:55 · PVG 07:55 · LAX 15:55 · JFK 18:55
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.