一、UML对VC的支持性不够好？
作为一种通用的建模语言，UML对与平台相关的编程语言建模支持性并不是很好（例如VC），而对与平台无关的编程语言建模支持性会好得多（例如JAVA），可以举一个很浅显的例子：可以根据UML建模后所得各种图例，映射成相对应的C++或JAVA的框架代码？但是对于VC中包含消息映射等与平台息息相关的界面框架而言，如何映射？我想这就是很多使用VC做项目的公司，觉得没有必要的使用UML的原因。二．如何更好的分离VC的界面层与业务逻辑层？
在用VC所作GUI项目中，界面层的编码无疑是一个冤大头，占有很大份量，让人无法抽身。甚至很多项目，完全就是界面层的编码，业务逻辑就放在界面层的消息函数中，界面做好了，项目基本也就可以完成了。因此你可能感觉到，在某些项目中间，80%以上的时间都可能在进行界面编码，因为VC的界面逻辑实在太强大了，以至于对于不是非常复杂的业务逻辑，总能找到适合的，可以融入的界面消息响应模块，做到最后，你可能最终发觉项目的界面逻辑与业务逻辑完全耦合了，这给程序的可理解性和维护性带来了相当大的困扰。怎么更好的划分界面层与业务逻辑层？
另外还向调查一下以下几个问题：
1、您所所过的VC项目中间，是不是觉得界面逻辑与业务逻辑的耦合性相当大,甚至基本上可以没有业务逻辑层次?
2、您所做过的VC项目中间，是不是80%甚至以上的时间，都在进行界面层的编码？
3、您是不是认为，界面层的复杂性是VC的一大弱点，但又提供了非常大的灵活性，正是它的魅力之所在？
4、您有没有想过，精通VC的核心之所在就是精通VC界面层编码，您是怎样认为的？三．冗余的数据类型，大大增加了VC的复杂性？
用VC做项目之所以慢，除了被界面层的灵活与复杂所扰之外，还有一个更重要的原因，是其难以上手，为什么难以上手？我认为其中一个重要的因素是冗余的数据类型定义：
C++语言是简洁清爽的，但是在VC中，你会发现多出了五花八门各种数据类型，而其中很多都异种同源，比如指针全部都是一个32位地址，但VC中有诸如VOID* PVOID* PLVOID*等等。比如句柄就是进程句柄表的索引，但是对于每一种资源，都给定义了一个不同的句柄类型。更别说最常用的，CHAR,LPSTR,LPCSTR,INT,UINT,WPARAM,LPARAM,LRESULT,WINAPI,AIPENTER等等等等，之间有多少重复的定义了。如果一个新手，面对这么多繁杂数据类型，根本就无所适从，会对自己写的每一条语句都抱有非常的不自信，不敢确定是否用对了，甚至对于VC高手而言，他也不敢肯定，他知道了VC中的所有数据类型及其真实含义。
变量类型是一种语言的核心子集，其他都是在子集上的扩展，它的复杂性也就基本决定了这种语言的复杂性。那么VC中为什么会出现如此多的没有必要的冗余数据类型？我想一个很大的原因是符合WINDOWS API规范密不可分的，如果是这样，那VC程序员脸面就有光彩了，因为您正和Mircosoft的coder们共用同一种编程规范呢。但是我还希望它简化，因为并不是每个程序员都必须具备Mircosoft coder们的才智，反过来说，程序员也应该严正的质问一下Mirocsoft：凭什么必须强迫我们学习并符合你Mircosoft的规范，我们只是想编程，只是想编程而已，对你的那一套没有兴趣！
在基本语义上，C++与JAVA的难度基本平衡。为什么会出VC与java开发在学习上的数量级产别？我想这正是Mircosoft一手造就的吧。四．VC项目的可移植性，不要太多考虑？
大话连篇者经常孜孜教诲曰：“要考虑项目的可移植性”，但我真不知，对于VC项目而言，该如何去考虑其可移植性。对于Windows系统，不同版本之间的转移，不会有多少问题，因为API一脉相承；
对于非WIN系统而言，VC项目的移植基本不可能，原因又在于API迥异。
可移植可真是大笑话，是各个平台制造商们冥想出来的恶意伎俩，却害苦coder们。如果微软想解决可移植问题，很简单，做一个Liuix版本的VC编译器就够了，如果想更彻底点，干脆统一各个平台的API吧，那时C++程序员就偷着笑了，因为像JAVA这种封装各种平台API的垃圾解释型语言而言，就没有生存的空间啦。
但是MS肯定不乐意的，因为如果Windows应用程序的源代码搬过去就可以成为liux的程序，软件供应品种丰富了起来，还会有什么人用windows呢？
作为一种通用的建模语言，UML对与平台相关的编程语言建模支持性并不是很好（例如VC），而对与平台无关的编程语言建模支持性会好得多（例如JAVA），可以举一个很浅显的例子：可以根据UML建模后所得各种图例，映射成相对应的C++或JAVA的框架代码？但是对于VC中包含消息映射等与平台息息相关的界面框架而言，如何映射？我想这就是很多使用VC做项目的公司，觉得没有必要的使用UML的原因。二．如何更好的分离VC的界面层与业务逻辑层？
在用VC所作GUI项目中，界面层的编码无疑是一个冤大头，占有很大份量，让人无法抽身。甚至很多项目，完全就是界面层的编码，业务逻辑就放在界面层的消息函数中，界面做好了，项目基本也就可以完成了。因此你可能感觉到，在某些项目中间，80%以上的时间都可能在进行界面编码，因为VC的界面逻辑实在太强大了，以至于对于不是非常复杂的业务逻辑，总能找到适合的，可以融入的界面消息响应模块，做到最后，你可能最终发觉项目的界面逻辑与业务逻辑完全耦合了，这给程序的可理解性和维护性带来了相当大的困扰。怎么更好的划分界面层与业务逻辑层？
另外还向调查一下以下几个问题：
1、您所所过的VC项目中间，是不是觉得界面逻辑与业务逻辑的耦合性相当大,甚至基本上可以没有业务逻辑层次?
2、您所做过的VC项目中间，是不是80%甚至以上的时间，都在进行界面层的编码？
3、您是不是认为，界面层的复杂性是VC的一大弱点，但又提供了非常大的灵活性，正是它的魅力之所在？
4、您有没有想过，精通VC的核心之所在就是精通VC界面层编码，您是怎样认为的？三．冗余的数据类型，大大增加了VC的复杂性？
用VC做项目之所以慢，除了被界面层的灵活与复杂所扰之外，还有一个更重要的原因，是其难以上手，为什么难以上手？我认为其中一个重要的因素是冗余的数据类型定义：
C++语言是简洁清爽的，但是在VC中，你会发现多出了五花八门各种数据类型，而其中很多都异种同源，比如指针全部都是一个32位地址，但VC中有诸如VOID* PVOID* PLVOID*等等。比如句柄就是进程句柄表的索引，但是对于每一种资源，都给定义了一个不同的句柄类型。更别说最常用的，CHAR,LPSTR,LPCSTR,INT,UINT,WPARAM,LPARAM,LRESULT,WINAPI,AIPENTER等等等等，之间有多少重复的定义了。如果一个新手，面对这么多繁杂数据类型，根本就无所适从，会对自己写的每一条语句都抱有非常的不自信，不敢确定是否用对了，甚至对于VC高手而言，他也不敢肯定，他知道了VC中的所有数据类型及其真实含义。
变量类型是一种语言的核心子集，其他都是在子集上的扩展，它的复杂性也就基本决定了这种语言的复杂性。那么VC中为什么会出现如此多的没有必要的冗余数据类型？我想一个很大的原因是符合WINDOWS API规范密不可分的，如果是这样，那VC程序员脸面就有光彩了，因为您正和Mircosoft的coder们共用同一种编程规范呢。但是我还希望它简化，因为并不是每个程序员都必须具备Mircosoft coder们的才智，反过来说，程序员也应该严正的质问一下Mirocsoft：凭什么必须强迫我们学习并符合你Mircosoft的规范，我们只是想编程，只是想编程而已，对你的那一套没有兴趣！
在基本语义上，C++与JAVA的难度基本平衡。为什么会出VC与java开发在学习上的数量级产别？我想这正是Mircosoft一手造就的吧。四．VC项目的可移植性，不要太多考虑？
大话连篇者经常孜孜教诲曰：“要考虑项目的可移植性”，但我真不知，对于VC项目而言，该如何去考虑其可移植性。对于Windows系统，不同版本之间的转移，不会有多少问题，因为API一脉相承；
对于非WIN系统而言，VC项目的移植基本不可能，原因又在于API迥异。
可移植可真是大笑话，是各个平台制造商们冥想出来的恶意伎俩，却害苦coder们。如果微软想解决可移植问题，很简单，做一个Liuix版本的VC编译器就够了，如果想更彻底点，干脆统一各个平台的API吧，那时C++程序员就偷着笑了，因为像JAVA这种封装各种平台API的垃圾解释型语言而言，就没有生存的空间啦。
但是MS肯定不乐意的，因为如果Windows应用程序的源代码搬过去就可以成为liux的程序，软件供应品种丰富了起来，还会有什么人用windows呢？
...........
wxWidgets使用面广吗？性能可靠吗？如果要深入挖掘win系统特新，非MFC+API不行啊
a: 不可能没有数据处理，逻辑层，除非是很小的项目。2、您所做过的VC项目中间，是不是80%甚至以上的时间，都在进行界面层的编码？
a: 不是，如果项目规划的好，界面部分完全可以和数据处理分开。人月的耗费主要看这个项目的偏重点。3、您是不是认为，界面层的复杂性是VC的一大弱点，但又提供了非常大的灵活性，正是它的魅力之所在？
a：同意界面灵活，但没有用过很多其他的语言，所以并不觉得界面很复杂。4、您有没有想过，精通VC的核心之所在就是精通VC界面层编码，您是怎样认为的？
a：这个，我宁可精通c++，这样更好找工作把。
.............
语言本来就是一个有限集，很容易掌握。难度其实是在平台与类库。精通c++那只是基础要求，在项目中间也只能编一些模块。离开API，c++根本没有实用的价值，这一点与JAVA很不相同。所以说C++其实只是个引子，关键还在于与平台相关的开发环境。
我一直很奇怪，为什么很多人尤其是学生推崇C++语言如何深奥和博大精深，该如何如何去研究。而实际上呢，在我看来，无论是C,C++,JAVA,在语言上没有太多难度区分。关键在于与平台融合后运用的难度。
所以我觉得：
1、精通C++(基本要求啦)，你只能编与系统无关的模块。
2、精通MFC(不精通C++能精通MFC?),你就可以进行最简单软件体系结构设计了。
3、精通平台特性，你就有能力编写具有创造性的软件了。
总结一句话：C++是基础的基础，没有太多可以研究的地方，如果把必要的掌握当成研究，那也太可笑了，应该把注意力转移到开发平台与设计模式上来。
有MSDN嘛！
...................
关于界面逻辑与业务逻辑分离，有谁能给些建议？