Flex为什么要"NoMVC"

 Flex为什么要MVC？

1、对不同用途的代码进行分类管理？降低耦合？

2、分类后的每个代码程序规模都不大，使得代码容易懂？

3、防止修改代码的时候把不该修改的地方误改了？

4、提高生产效率（代码少？容易编写？）？

5、代码易读，易懂？

6、代码容易单独调试？

7、减少重复代码？

8、代码运行性能好？

9、易维护？

 

--------------------------------------------------------------------------

1、MVC框架（如Cairngorm 、PureMVC）通过使用各种设计模式，达到对代码进行分类和解除紧密耦合。这个目的是可以达到的。

      但是，对于展示层代码（Flex）是否有这个必要？

      Flex代码粗线条来看，有几种处理内容：

      （1）画面代码（窗体，按钮等可见组件）

      （2）操作画面的代码（对组件的控制：如改变状态，取得组件的输入数据，为组件赋值等）

      （3）编辑画面上的输入数据（比如进行数学计算，业务逻辑判断）

      （4）与后台服务器的交互

 

        （1）和（2）的关系都是紧密的。即便物理上把代码分类，这些代码也很少能够重用，所以没有必要分来。放在一起可以使得代码易读，易懂 。

        （3）是要通过（2）来获取数据画面上的输入数据的，关系也是很紧密的。使用函数库或功能类库就能达到从功能上对代码进行分类，并代码重用 的目的。

        （4）也是可以通过函数库或功能类库就能达到目的，并代码可重用。

       

2、MVC分类后的代码程序会小？

      代码过于集中从而变得体积庞大，是否需要拆分，如何拆分，这和MVC没有一毛钱的关系

 

3、MVC不能解决误改的问题。

      如果大家做过对日软件开发，应该知道，对于代码的修改，特别是已经交付使用的代码，其修改是需要进行严格验证的。

      通过对修改前后代码的Diff确保其只修改了该修改的地方，防止误操作。

      通过充分的测试和严格的验证确保其修改符合原始意图。

      防止误改是通过工程手段来进行的，而不是通过MVC。

      （敏捷开发方式是否如此不得而知）

 

4、地球人都知道，使用MVC会增加很多代码（工作量）

 

5、这可是仁者见仁智者见智的事儿（个人觉得只要熟练了，都能看懂。不过新手可就感受不同了，MVC自然需要多些时间成本）

 

6、MVC分类后的代码一部分可能容易进行单独测试，而另一部分由于缺少上下文的支持变得难于单独测试。

      （把原本应该放在一起的代码分开来测，有这个必要吗？）

      你做过这种分来单独测试的工作吗？

 

7、恰恰相反，重复代码会多 

      MVC框架对程序结构进行了硬性约束，代价是降低了程序的灵活性。

     MVC后，各个部分的代码过于独立，缺少能够承上启下环境，只能借助于第三方数据载体来传递数据。

      Cairngorm 中同一个画面的不同command 会存在一些重复代码吧。

  

8、MVC框架隐藏了太多的细节（如类型转换，类型匹配，函数调用，参数传递，事件收发等等），必然影响性能

 

9、同5

 

-------------------------------------------------------------------------------------------------------

 

我认为不使用MVC，而原生态地使用Flex是非常值得推荐的做法。

如何提高代码重用？ -----函数库

如何防止误改？          -----工程规范控制 + 质量控制

如何规范代码的编写？----完善的规则 + 标准代码编写范例 + 质量控制

 

思考一个问题：

我提倡尝试“NoMVC”，是否仅仅为了NoMVC而NoMVC？是否有充足的理由认为应该NoMVC？

反过来，如果使用MVC，是否仅仅为了MVC而MVC？是否有充足的理由认为应该MVC？

 

曾经有人质疑我们是否先入为主地认定：使用框架就是好，不是用框架就不好。

无论主流是什么观点，都要避免盲从。

转自：http://blog.csdn.net/tiangej/article/details/7096875