有同感，觉得Delphi的可移植性差了点。团队开发若没有强制的规范，开发出来的代码其后续维护将不可想象！！

界面架构楼主上面说的4点，在我的开发框架中都已经解决，就是没有想到没找到可用XML定制的界面解决方案！

长江后浪推前浪,delphi将漫漫被新型的开发工具挤出；不管怎么样的开发工具对于一个团队来说，都应该有自己成熟的框架、规范、开发流程

任何一个成熟技术团队 或者 开发公司 都有自己的framework 

系统的框架才是软件的灵魂,在开发中,由于种种原因,项目组成员对于软件开发的认知度,项目的工期等原因,导致整个项目的开发过程中,软件开发的统一做的不尽人意,代码的粗枝乱造,界面的风格不一郅,业务的胡乱堆积,使系统的质量大大降低
------------------------
相当认同

jf

up

实际上现在好像各种开发工具发展的最终目标是如何快速开发，而运行效率变成了其次，在追求速度，不要效率的时代，这是很正常的现象

up

1、说Delphi的开发方式对OO运用的比较少
这一点根本站不住脚，如果思想没跟上，用了class一样写不出OO的代码
2、说Delphi对MVC运用的少
这是因为VCL根本就没有使用MVC，MVC不是灵丹妙药，本身也有很多问题
好好想想，如果MVC够先进，C#为什么不用？
VCL本身就不是MVC的，在VCL之上构筑MVC，是一件很费脑子的事，
构造出来的东西是否优美，也得打个问号。
如果脱离VCL，另搞一套组件框架，还得考虑生命期的问题，
win32 api属于快被淘汰的东西，在它上面搞得再完美都没有多大价值
而.net framework本身已经很全了，
基于它再封装一个框架，很容易跟VCL .net一样，落个不尴不尬的地步
3、搞VCL那种基础的框架是件费力不讨好的事，没有两把刷子最好不要轻易尝试
像Hibernate、ECO那种面向特定领域和业务层面的框架倒是有可行性。

学习了....

专业抢分

听楼主说的有点像想弄个业务架构平台的意思，不过用Delphi去开发这么一个平台是不是有点太困难

呵，谢谢大家的关注！！！
首先，
我做这个框架第一个是要在日常的开发过程中，能够有一套底层的东西，不用从头再搭一个程序的框架！！
其实，
框架里会集成一些公共的方法、函数（HELPER）类，里面有一些在实际开发中的技巧以及各种控件，组件的特性，如：dx***,ListView等等。
能逐渐完善，将以往掌握的一些东西完善到框架中，达到更快速、高质量开发的目的
针对:
king_xing 
有同感，觉得Delphi的可移植性差了点。团队开发若没有强制的规范，开发出来的代码其后续维护将不可想象！！ 

界面架构楼主上面说的4点，在我的开发框架中都已经解决，就是没有想到没找到可用XML定制的界面解决方案！ 
-------------------------------------------------------------------------------------
很希望能把你的框架的东西共享出来，大家共同研究一下，关于XML界面定制，个人认为没必要，如果非要定制，用Delphi自已带的DFM就可以了，没必要再自已做了
XXSingle 
长江后浪推前浪,delphi将漫漫被新型的开发工具挤出；不管怎么样的开发工具对于一个团队来说，都应该有自己成熟的框架、规范、开发流程 
-------------------------------------------------------------------------------------
认同XXSingle的观点，delphi虽然可能不久的将来要退出或暂时退出（大家可能都不想有这么一天：（），但是无论任何语言，工具，其核心的思想是一致的，
现在我在框架里用到的一些思想，模式都是参考了.Net,Java等 

ydlchina 
实际上现在好像各种开发工具发展的最终目标是如何快速开发，而运行效率变成了其次，在追求速度，不要效率的时代，这是很正常的现象 
-------------------------------------------------------------------------------------
认同，现在的各种开发工具，都会以快速开发为目标，从而各种开发工具会集成各种生成向导，生成工具（插件等），完成各种模型的定制，在现在这个硬件
越来越便宜，硬件的更新速度完成能平衡软件在性能上的瑕疵。 

sdzeng 
1、说Delphi的开发方式对OO运用的比较少 
这一点根本站不住脚，如果思想没跟上，用了class一样写不出OO的代码 
-------------------------------------------------------------------------------------
sdzeng说的没错，如果没有好的OO方面的思想或是工作经验，写不出什么来。我所说的是，现在DELPHI开发团队普遍存在的一个问题（可能是偶见到少的原因）
，在开发过程中，特别是应用系统开发，OO思想的运用是少之又少。

2、说Delphi对MVC运用的少 
这是因为VCL根本就没有使用MVC，MVC不是灵丹妙药，本身也有很多问题 
好好想想，如果MVC够先进，C#为什么不用？ 
VCL本身就不是MVC的，在VCL之上构筑MVC，是一件很费脑子的事， 
构造出来的东西是否优美，也得打个问号。 
如果脱离VCL，另搞一套组件框架，还得考虑生命期的问题， 
win32   api属于快被淘汰的东西，在它上面搞得再完美都没有多大价值 
而.net   framework本身已经很全了， 
基于它再封装一个框架，很容易跟VCL   .net一样，落个不尴不尬的地步 
-------------------------------------------------------------------------------------
个人认为MVC还是一个比较好的思想，C#现在的3.5应该要把MVC加进来了！！！用MVC只是想把DELPHI的开发人员的思想从
DELPHI固有的快速开发模式中解放出来，这样为以后使用其他语言及工具打好基础，可以想象，从JAVA<->c#比较容易，而从Delphi<->Eclipse,VS较难的

3、搞VCL那种基础的框架是件费力不讨好的事，没有两把刷子最好不要轻易尝试 
像Hibernate、ECO那种面向特定领域和业务层面的框架倒是有可行性。 
-------------------------------------------------------------------------------------
赞同，首先，我们团队的人员有限，精力有限，能力有限，所以对于框架最终能成什么样，我心里也没有底，但我想通过这次实践
唤起大家对Delphi方面框架的支持，Delphi现在的地位已不如以前了，希望剩下的还从事DELPHI开发的朋友能够齐心做出一些东西
来，为自已也好，为了延续DELPHI的生活也好，做出自已的一点贡献！！！

关于框架，现在只讨论了界面，后续还有关于数据库层，业务层设计，我的想法是，最终做成一个工具，向导，自动完成数据库与执久化之间的转换，结合
界面框架，自动完成一个程序雏形的建立，程序员只要写一些业务相关的逻辑，组合，判断等，就能完成一个小系统的开发！！！ 希望大家能多提出一些宝贵意见！！！谢谢！！

 

觉得VCL的代码是很优美的。

to Bear_hx :
觉得VCL的代码是很优美的。
---------------------------------------
VCL真的是美极了！！！！他是由美丽的Pascal写成的！！！呵

关于未来的东西，我们很难去想象，很多都是可以人为可以去改变的东西。

我觉得,在开发过程中,尽量的采用面像对像的思路去写,因为在实际的工作中每个人的想法,技术以及业务方面的理解都不太一样,所以只能尽量的去做喽.
其实delphi的源码都是面向对像的,写的很好的.

学习

看了delphi的VCL源码,有助于理解其它的框架

我也来抢分

UP

我的代码超级烂，很是苦恼，找不到解决问题的良方。

小弟很菜，但还是觉得VCL就像是一座宝藏，值得我们去挖掘！

zxf_feng 
我觉得,在开发过程中,尽量的采用面像对像的思路去写,因为在实际的工作中每个人的想法,技术以及业务方面的理解都不太一样,所以只能尽量的去做喽. 
其实delphi的源码都是面向对像的,写的很好的. 
 -------------------------------------------------------------------
面向对象的方法就是一个能用的“框架”，但每个人的理解不一样，没有一个统一的规范，不象JAVA里的框架那样，将面向对象的一些思想“固化”，DAO，VO，PO等，以及Hibernate,IBatis等执久化框架为用户提供了一个标准的开发模式，DELPHI中传统的RAD开发，已经不适合现在的这个时代了！！
Delphi的VCL确实很美，象花一样美，但我们有些人写的代码就象屎一样烂，最后呢，写出来的产品就是鲜花插在了面屎上，那是一种什么感觉，大体应该都清楚吧！！

希望大家能说点实质的，把自己的一些“货”都倒出来，晒一晒！！！！

顶一下：）

 我是菜鸟，对楼主的话题很感兴趣！自己做的一些小东西，都是拖一拖控件，类也没用上，顶多用几个公共里单元,代码根本无法重用！

帮楼主顶吧！！

关于数据层的相关设计思想已经放在博客中，有感兴趣的朋友请访问http://blog.csdn.net/martinwang

看了楼主写的东西，深有同感啊，从半年前开始，我接手了一个经过无数人修改之后的一个程序，Build一次的代码量就在30万行左右，10几个窗体，每个窗体都对应一个近万行的Pas文件，所有东西都放在click里面，从数据库里面取数、数据分析处理、数据显示，全部都在一个click里面完成，维护起来真是难于上青天。我现在也是希望能够重新进行设计，把数据层、业务层和显示层尽量分开，做出几个公共pas，提供各类不同的函数和方法。但是还没有一个很明确的想法，现在就泡在这里跟大家取经呢，还希望能跟楼主多交流:)

MARK

楼主的态度和对别人意见的认同部分都值得表扬 嘿嘿

注意把握度，什么都放到你那个框架中不一定是好事

好用，快速，方便就行了，不是所有的业务和界面都能提炼的

其它我到是对于Delphi团队的开发意见是，平时开发时，多提炼

多总结，多积累，以后的再开发会省时省力，不用非搞多大的

框架才是最好，毕竟公司不是研究机构，把握度最好。

第一，对软件设计的分层考虑
 1。界面响应层。只提供界面和响应。不能有多余的逻辑实现，类似OnClick的事件只处理对低层逻辑类的方法调用。
 2。逻辑层。提供功能实现。不考虑文件存储结构。
 3。存储层。只提供文件存储结构。
 以上三层使用interface统一设计。这样可以使用三个开发小组分头负责，一个总设计师。总设计师必须规范interface.通常来说，界面改版最多，其次为逻辑，其次为文件。分层后代码维护比较方便。
第二，对文档的分层管理。
 1。全局unit目录层。所有的项目公用，包含dll
 2。项目全局uint目录层。
    --项目资源
    --项目目标
 3。项目小组目录。

设计固定的框架有时候会有很大的成本。而且业务针对性比较强。其实主要的是软件设计开始前准备工作不充分，临时改版多，会极大的造成代码和逻辑混乱。软件设计前的准备就是框架的雏形。并且最适合你。

顶

一直都认为DELPHI的开发要OO

帮你顶

加油 接分

感谢楼上几位的意见：
1.现在的架构在测试，整合阶段，将对测试后的架构进行BPL打包，进行严格的版本管理，质量管理
2.准备将一些常用的操作函数分类：字符串处理类（UnitStringUtil.pas)，时间处理类，网络类等，仍然采用BPL打包
3.不断将一些新的思想，新的函数加入，并对原有的一些BUG进行修改
4.采用一些开源的工具进行整合，迭代，如：Svn实现最新代码的下载，Want实现自动编译，DUnit实现自动的单元测试，DLog自动记载日志，Dctd生成API文档，Want实现版本的自动上传，日志的自动发送
后期：
1.引入WEBService,Json等远程操作，REmObject等暂不考虑
2.引入AOP,IOC的相关的特性，为FrameWork里增加此特性
3.引入即时通讯组件，基于COM标准模式，实现扩业务系统（不是扩平台）的调用
4.引入ROR，将ROR的敏捷特性发挥出来，由ROR负责服务器及业务的开发，DELPHI完成前端的开发
.............
5.扩平台的业务整合,Java,.Net,Python,Ruby等

总之，将一些新的技术，新的特性，做为DEMO，组件，服务等引入到FrameWork中，为以后开发形成一整套的标准，演示，文档，模型等，加快开发速度，完善产品质量！！！！
我在OSDN已做了申请，我将把上述的内容开源，希望大家真正参于进来！！！

層是要分的，兩到三層就行了，因為層內部還可以再細分層，所以大的分層只要兩到三層就足夠了。

上面提到的界面响应层。只提供界面和响应。不能有多余的逻辑实现，
界面與邏輯往往是相關的，一個响应幾乎要對應一個界面邏輯，將業務邏輯與界面邏輯分離確是不易。因為如果完全分離，恐怕CS開發模式的對應的強大功能要大打折扣，CS方式的優點：軟件的易用性與功能強大，這不能丟，否則不如用BS方式開發程序了。

建議界面响应层不作為框架出現，可作為程序庫方式提供。系統是否設計為"業務邏輯與界面邏輯分離"則交由實際系統來決定。

只關注一個重點，要比面面俱到做得更好。

楼主，你醒醒吧！

虽然你可能会骂我，不过我还是要说，你上面说的东西，除了一些空洞的技术和非常理想化的期望以外，我并没有看到什么特别有价值的东西。

但是如果你真的要做，我也提提个人的建议：

1. 制定简单明确的项目目标和期望
2. 集中所有资源做最有价值的部分
3. 不要写重复的东西（比如，常用函数库），常用的操作函数直接使用JCL (JEDI Code Library)
4. 初期不要考虑单元测试、API文档等等
5. 尽早接受反馈和检验，及时调整方向和进度

to PPower :
谢谢你的回复，界面层主要是
1.完成系统的风格的制定（按钮摆放，大小，查询，统计，数据添加方式）
2.完成界面的统一控制，采用消息（Message)或是回调（CallBack）方式实际界面、窗体间的弱耦合
3.现在的设计及开发大部分时间是在业余时间进行的，所有在让人感觉比较乱，对于框架中的每一部分，都由很多个“点组成”，我也考虑到相关的点，争取能进行短期的迭代;
to ZuoBaoquan :
谢谢你的指正，希望能通过这个框架能使大家能够讨论一下框架及底层的东西
1.   制定简单明确的项目目标和期望 
其实目标在上面已经提过，可能你觉得上面的目标有些不切实际或是不明确，其实上述列出的相关的技术我都进行过详细的预研，都进行过项目外的简单实践，如果能把团队开发人员定下来，接下来就是编写用户故事、迭代等
2.集中所有资源做最有价值的部分 
我现在的想法是将一些先进的、流行的（不追着新技术走，就没法生存啊）技术，框架语言等能与现有的DELPHI结合在一起，让DELPHI程序员也能看到DELPHI的扩展性，系统兼容性等，为学习其他技术、语言提供一个实践，开发平台
3.要写重复的东西（比如，常用函数库），常用的操作函数直接使用JCL   (JEDI   Code   Library)
重复的东西是不会写的，特别是一切技巧性的东西，论坛里好早就讨论过这些东西，但是现成的东西间也存在对比，如字符串处理，QSTRING库就比其他的一些字符串处理要高效的多，通过这样不断的积累形成一整套不断更新的函数库，为开发人员提供标准的、分类明确的API
4.初期不要考虑单元测试、API文档等等 
单元测试是一定要做的，最近一直在看敏捷，XP方面的东西，深知单元测试及TDD在开发中的重要性，且为其他人员提供DEMO及API应用示例，提高程序的质量，何乐而不为；API我前面说过了用DCTD，只要写标准的注释自动就会生成；
5.   尽早接受反馈和检验，及时调整方向和进度 
我准备采用敏捷的方法进行开发，快速迭代，增加框架REAlease的速度，能让大家早看到东西，及时指正！！！

再次感谢大家的意见及建议！！！
PS：工作快6年了，在这段时间自己的感悟挺觉，最近在读周爱民（delphi的大大，大家应该知识吧）的大道至简，非常认同，对于面向过程，面向对象等做了详细的论述，还没看完，大家有时间也可以看看！！！会对程序开发有一个新的认识

LZ很谦虚，加油！

呵呵，我也正打算做一个小系统平台,目标是希望能够自定义界面,实现脚本控件流程,实现界面和数据库无关性,使其能针对各种大小型数据库.共同加油啊,顶你.

顶一下，佩服楼主的精神，虽然觉得没什么太大的实际价值，但如果可能的话，我也参与这个项目。

做系统架构的人很重要，试问能有几个人能有这种真正的才能——————都是些叫着经理啊，CTO的混蛋

顶       UP       UP   
狂接分！！！！

to suiyunonghen :
目标是希望能够自定义界面,实现脚本控件流程,实现界面和数据库无关性
1.框架里也会把这一部分加入的，我现在的项目中就采用此结构，由于项目的特殊性，采用此架构
物理表----->物理字段------->数据表-------->数据字段----------->查询定义------------>表格样式定义------------>录入界面定义
  ||        ||              ||            ||                 ||                    ||                      ||
记录表名     记录字段名类型    虚拟表         虚拟字段              定义虚拟表的查询        定义虚拟表的样式           定义录入界面
具体的结构如果有机会再和大家讨论，由于这个框架不是由我进行设计的，在开始使用的时候还是有一些地方比较麻烦，如果经过一次重构的话，相信无论从
性能上还是易用性上都会有一个大的提高！！！用了这样的FrameWork，可以扩展到其他的应用平台(java,.net,PHP等）
to zzllabc :
感谢你的关注，到时会拉着你的，呵：）
to luoyanqing119 :
做系统架构的人很重要，----同意，架构是一个标准，一个思想，试问，如果人没有了思想，行事没有了标准会怎么样，更何况人编写的程序
试问能有几个人能有这种真正的才能——————都是些叫着经理啊，CTO的混蛋
-----其实不弄架构或是做技术的经理，CTO们所做的事，是上升到一定高度的，团队管理，建设，客户，内部关系协调，公司未来技术，产品路经制定
等，这些才是一个软件公司的生存之本，如果都来弄程序，写架构，那么公司迟早会关门的，以上是个人愚见，有不对这处请见谅！！！

这几天忙没来看贴，看看大家还有没有什么想说的！！！最后我将根据大家的想法进行后续一些工作！！！

认同楼上各位高手的看法，难得遇到知音，希望能与大家为友，我先自我介绍一下：

软件框架确实是软件的核心，这几年我也一直在不断完善升级自身的软件框架，我现有的框架，已拥有的功能有：

1. 公用认证与通用权限管理模组，也就是说只要写一个窗体并封装成bpl放到我们主执行档下面就可以登记、注册并纳入权限管理体系；

2. 通用报表定义模组，我是嵌入excel来完成报表模版设计，我们的erp中任何一个子系统中，都没有包含一行与报表有关的代码；

3. 通用查询定义模组，所有的查询程式均可以透过工具进行建立并存于数据库(一样纳入权限管理)，用起来与delphi写的一样；

4. 整个系统均为三层结构，浏览器界面，主执行档实际上就是一个浏览器(还是bpl加载器)，这样所写的任何模组(窗体)，都可以跨互联网运行；

5. 内含通用版本更新与控制工具，所有的系统均可以多层级分发，自动升级；

6. 通用安装程式，自动繁简体转换等...

有了这个框架，假如想编写一个如文档管理系统，那我们只需要编制3种程式：1.单据维护窗体；2.特殊运算窗体；3.后台逻辑组件；
其它的与基本资料维护(单表)、各类查询统计程式、各类打印报表模版，安全认证，自动生成等功能，全部不用再做了。或者说一个库存管理系统，只要写10来个左右的pas文件，并封装成bpl放在主执行档的bin目录下，就可以成为一个很专业的系统了，这开发效率上升了好几倍(少做好多事)。

当然，这套框架也有不足之处，其中比较烦的就是加载未知bpl的自动内存检测、后台app的对未知bpl的热加载/更新功能，一直没有设计得很理想，还有负载平衡的部分，也难以用最聪明的运算量动态均衡，而只能使用比较原始的用户数来均衡...

以上是我的一点试验，献丑了！希望能抛砖引玉，有兴趣研究框架的，欢迎大家一起到我的群组深入讨论。

我在CSDN的群组为：制造业ERP讨论组(网址：http://groups.csdn.net/ERP2008 ) 

补充一点，现在我正在研究Java相关技术，觉得Java的很多东西，在Delphi中都可以类似实现，比如Spring, 比如JBoss等，但比较烦的一件事就是我刚讲的，如何让执行环境可以加载未知bpl时，可以监控它的运行，特别是内存错误捕获、内存泄露检测，一直没有好的做法，不知大家有没有好的经验分享一下。

DELPHI的特点是快速入门，开发迅速，
但也有很多毛病，例如界面和代码的高度耦合就是一个很大的问题，写代码方便，维护困难。
当然这不完全是DELPHI的责任，主要还是项目规划和设计的问题。

举个例子，一个串口控制设备的程序，有20个按钮，实现多种功能的设备控制，每个差别很大。
    多数的做法是直接给每个按钮事件写代码，这个方法很快，但可维护性很差。

    如果设备多次升级修改协议（这是经常发生的事情），而且要兼容老的协议，
    你只能在每个事件中改进，整个文件越来越大，越来越复杂，看到都头痛，谈何维护。

    一个合适的做法是为设备建立一个单独的单元或动态库。
    设备每个升级都建一个新的单元或动态库，新的处理判断版本，不是新版本调用上个版本的函数，没有变化的调用也调用上个版本的函数，有变化的改进，最后简单的修改界面上的调用就搞定了。
    虽然敲的东西可能多些，但维护起来简单多了。

另外，介绍一个我看过最好的DELPHI数据库开发的例子：
    一般的数据库开发，都是利用控件，再和数据库操作混在一起，稍复杂一点头晕的要命。

    我看过一个软件，把数据库操作抽象成各个功能调用Db_XXXX，分类成多个单元，
    而每个界面做了多个Show_XXXX函数，用于显示数据库信息，
    主界面多数实现只是调用Db_XXXX、Show_XXXX和很少必要的界面同步代码，
    这样的程序一看就是享受，不到一个小时一个很复杂的软件就看明白了，维护起来也很简单。

这些都是我参与过或看过的东西，希望对大家有所启发：
    功能和界面不要过多的耦合，如果赶时间可以先做出了，有时间时一定要整理好。
    这样就不会见到这么多抱怨前任的帖子了，如果你写了一堆垃圾，别人也会抱怨你的 :)

写完这些，又看了一遍帖子，感觉扩展DELPHI的一些实用功能是必要的，但没必要过多的追究DELPHI或VCL的不足，不足的只是我们。

个人认为：软件开发是一种思想、经验、习惯的整合，
    思想：让我们明白我们要干什么，有哪几种方案可以实现
    经验：告诉我们各个方案的优缺点，确定一种方案
    习惯：让我们勤劳的写出整洁漂亮的代码

如果你能完全明白，加上你的知识积累，你就可以跳出具体编程语言的框框，看到和善用各种编程语言的优点，规避它们的缺点，
（Windows下很多好软件都是用VC实现功能，DELPHI、VB、BCB实现界面）

--------------------------------------------------------------------------------------
如果你翻出以前的代码，没看出多少让你厌恶的地方，你已经是高手了 :)