探讨一个界面框架设计的问题。

Question

如果你需要处理显示数十种数据呈现。那么针对每一个菜单难道都要做一个VIEW/CHILDFRAME对应么？应该有更好的方法进行重用设计。我感觉针对每一个视图呈现如果都做一个view class对应，那么将大大影响开发效率和灵活性。于是我想到了开发一个框架，仅仅负责数据的显示。数据的处理和逻辑分析，交给其他的模块处理。不知道大家对于这种情况的处理都是如何考虑的？最典型的应用就是一个数据可能需要多种呈现形式：表视图、chart视图等。如果有那么几十种，我们不可能都写死了吧。怎么做到能够支持外部的配置，这样新的需求出现后就不一定需要修改内部程序，也许仅仅需要修改配置文件即可达到界面改头换面的效果，并且满足了数据内容的变化需求。请大侠们谈谈这个话题。

Answer 1

显示部分和控制部分分开，MVC模型

Answer 2

楼上2位给出的是一个框架。我知道MVC模型。现在具体的问题是设计多种类型的视图有关。
我想寻求的一种方案是：针对不同的视图形态，找到一种外置的配置方案以应对变化。举例来说：
视图（1）需求：10列，数据源01。
视图（2）需求：20列，数据源02。
视图（3）需求：5列，图表支持，数据源03.针对这种多变的需求，V视图更像是一个通用的可配置界面，界面的元素都是可以支持配置的。当然数据源也是可以可以支持配置的。MVC概念涉及的是针对一种类型下，V负责显示、M模型、C数据逻辑控制。
我想做的是在MVC的基础上更加泛化的支持。

Answer 3

...想想在MVC架构上继续包装, 做出让开发速度更快的东东出来, 这样比较实际

Answer 4

难道MFC的文档视图模式不相当于MVC吗(Frm做控制，View做显示，Doc是数据)??M$提供的CView和CDocument就是最抽象的视图和数据类了，
因为想做到通过外部配置文件来改变数据或视图，不管控制方Frm从配置文件里读到什么内容，
只要控制方Frm使用CView*，CDocument*就算做到了抽象。
但具体数据是什么，怎么表现，CView1->CView,CView2->CView,CDoc1->CDocument,CDoc2->CDocument...这些一个也少不了，如果想改的话也应该仿照M$的文档视图结构来改，...关注吧，看看大家怎么说哩

Answer 5

不管怎样，你还是需要写对应View来显示吧？

Answer 6

我这个想法主要就是为了减少变动对开发的影响，另外也可以提高开发的效率。比如一类数据的表现形式都是CMyView1类型，那么只要把显示样式确定，至于显示什么数据、显示多少数据、数据操作逻辑都可以通过外部配置完成。当然为了实现这一功能，需要抽象再实现一个响应的类似document的数据管理中心，我是采用的一个专门的数据管理模块进行实现的。并没有完全使用MFC的document。另外，MFC DOC/VIEW就是MVC模型的一个具体实现。

Answer 7

楼主功能实现了可不可以共享一下资源，学习下，可以的话发工程到[email protected]，谢谢

Answer 8

什么VIEW不VIEW的, 最好学习一下DELPHI或C#, 那种架构才叫快

Answer 9

其实在C/S模式下也有MVC的概念，比如现在很火的DirectUI界面库，页面显示是配置的，空出的函数就是填业务逻辑，显示和逻辑分开了。www.bodsoft.com，楼主试试这个

Answer 10

是的。我的工程就是C/S架构的应用。CLIENT想实现更加泛化的MVC支持。

Answer 11

呵呵，居然发现你这个网站的实现和我的想法还真的很类似哦。MS的DirectUI技术也是使用的类似思路？