delphi多层架构设想，说的都有分

1.在delphi多层方案里midas在数据处理上（将数据打包发送中间层）确实很方便，而且高效。可是我感觉midas的本身结构就将中间层的数据和逻辑耦合到了一起，在大项目的维护上很不好并且也不符合oo的思想。
我也使用过c#来设计多层系统，基本上思想是这样：客户端（传递类实例）-〉webservice->逻辑层-〉数据持久层-〉数据库。在客户端只涉及表现层的东西，对于数据的逻辑都放在逻辑层，并且使用持久层进行数据的维护，我觉得这样的架构维护方便，在客户端很多的时候部署也很方便（逻辑层的修改只需修改服务器端）。
在c#\java上持久层的资料以及代码生成器真是应有尽有，可我现在奇怪的是delphi在这方面却是空白（我所了解的很多公司都不是采用的上述方法），网上关于
delphi o/r方面的资料也是了了可数，确实使用了o/r映射会使开发的工作量要大些，可对于一个大型的软件而言软件的可维护性和健壮性才是最主要的。为何有这种现象呢？我本想使用delphi来设计一套持久层，在此之前我想先听听大家的意见和见解
2.如果采用多层的设计方案，那末客户端和逻辑层的连接是否就只能通过webservice来实现，是否还有其他的方案？

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

我觉得Delphi也是非常郁闷的，很大的一个特点就是你没法将逻辑层和数据持久层进行分离，要么就是分离了写起来特别难受，代码自动化也不好弄。还是遵循这种思想吧：先做好系统架构架构方面的。过于设计也是不提倡的。
我以前用C#,现在用Delphi，刚开始郁闷架构，现在郁闷它的TDbGrid。
operfume(橘子香水):采用持久层效率是比使用原生的ado数据维护效率差一些
                  1. 可这样做的最大的目的是降低逻辑层和数据层的耦合，这对于一个大的项目的维护是很重要的。
                  2.减少频繁的对客户端的更新
其实delphi的多层架构分得不是很明显，做了三年多delphi了，对多层至今没有一个明显的认识
可能是我不了解C#，所以看楼主的问题有点不懂。
1.用MIDAS，客户端完全可以只使用数据而不捆绑逻辑，逻辑可以在服务端实现。
  不知道楼主为啥认为MIDAS一定是数据跟逻辑不能分？
2.您可以试一下INTRAWEB，它实现B/S结构，相当吸引人的工具。
  不过不知道能否支持楼主的大系统要求了。
另外想问一下：LZ想设计的持久层是为了达到什么目标？
因为DELPHI里都有持久层的工具：ADO那些。
hawk_e2e(hawk_e2e):1.MIDAS的客户端确实只使用数据而不捆绑逻辑，而我问你：在你的中间层里你能很好的做到数据跟逻辑的分离吗
2.INTRAWEB确实是个很方便的建网站的途径
3.持久层：无非执行的是数据存取操作，之所以要使用持久层就是我们要在多层结构的系统中对数据进行存取。ADO、bde...从某种意义上他们是实现的持久层的功能，可对于系统中的持久层来说他们都只是持久层的一部分或者说是一个工具。
可能是我没做过大型的系统吧，所以只能讨论一下。感觉上DELPHI不适合开发大型系统，
所指的大型就好像一个城市的社会保障系统这样的规模，因为缺乏运行环境的支持，譬如：内存回收机制等。
1.如果你指的是SPRING里展现数据跟业务对象的自动映射机制，DELPHI里确实没有，需要你开发来支持。不过，有没有必要完全像SPRING那样分离就视乎情况而定了。
2.INTRAWEB可以用来建网站，而且很方便，不过它主要是为了WEB应用而设计的。
3.如果你想开发像HIBERNATE那样的持久层机制，可以。不过，有多少DELPHI开发的系统需要一个持久层来管理数据存取呢？
“感觉上DELPHI不适合开发大型系统“
我很不同意这个观点，hawk_e2e(hawk_e2e) 可以去了解下现在软件业（erp等）的绝大多数winform系统是使用那种语言。
在winform上我依然认为：‘delphi是winform的王者’
加入 Delphi 群 14507689 ,里面有高手
楼主好像老是想用DELPHI做大型系统似的。哈哈。
就算是一个集团的ERP又能有多复杂？怎能跟一个城市的社保系统的规模相比。
我也只是打了个类比。个人认为在一个大型的系统里，对运行环境的必要支持是很重要的，如：避免内存泄漏，避免引用非法指针，对关键资源的保护（即安全性）等，否则在设计上和测试上要花很多功夫，而且稳定性还不一定能保证。
看来我们都跑题了，
言归正传：
     如果使用语言delphi，在一个winform系统上，有设计持久层的必要吗？？原因我现在的意见是：需要，1.这对于系统的后期维护有好处，逻辑清晰
                      2.使得系统再日后再挂web版等的系统很方便（只需设计表现层）
没什么好处，如要挂Web版会有好处。如果作为一个框架产品，具有一定的通用性，那么需要持久层，如果是单一产品没什么好处。只会增加复杂性。持久层隔离数据库特性的意义不大，很多数据库驱动已经有这些作用了。逻辑清晰不一定会减少维护的工作量，增加一个层就意味着需要定义上下接口，多一个接口使用约定，加上其它的数据结构转换造成的工作量，开销不小的。此外，相对具象的持久层需要表达对象之间复杂的互动关系时候尤其困难，数据表之间的关系单纯、全面而且有统一的处理方法。用对象之间的引用来表达数据表中记录的键关系，吃力不讨好的事情。如果，减少对象间关系的表达，仅作为数据表的对应物，那还是可以接受的，但是这样的对象已经有现成的东西了，并不需要做。
java中的很多东西并不是很好的，要考虑到java的应用环境，他应用的底层平台千变万化，管理员远远多于程序员。所以用它做的东西必须要有高度的抽象性，能够通过管理方式而不是编程的办法来解决平台差异问题。实际上这么做是方便了管理人员，增加了程序的复杂性。java中有很多的东西没有标准化，没有事实上的惯用准则，也造成这种状况。MVC很受推崇，实际上MVC是很低效的。虽然我们惯用的事件模型倍受指责，但是他的确简便灵活。
>所指的大型就好像一个城市的社会保障系统这样的规模，因为缺乏运行环境的支持，譬如：内存回收机制等。Delphi在社保系统中的成功案例多着呢。一个城市的算什么哦，以前我们的省社保都是用delphi完成的。
Java 为什么会有那么多设计模式，就是因为java开发不方便，如果不采用模型固定的方法，开发出来的东西效率非常底下。所有才引入了很多的模式来解决效率的问题。
从BlueTrees(蜗牛) 的发言看，说出这么多问题，是属于还没有掌握设计的缘故，而不是分层本身的问题。
多层系统开发最重要的是选择好中间层，好与不好千差万别哟。
如果要delphi来开发，可以用一个国人自己开发的中间件（www.quickburro.com）：QuickBurro系统较准确地抓住了分布式应用开发的核心问题，不仅分布式开发的“数据库-中间件-瘦客户端”这种三层模型设计思想得到了很好的贯彻，同时进一步向程序员提供了实现横跨Internet广泛区域内的软件开发共性部分：组网、命名、寻址、连接维持、远程数据交换、数据压缩传输、加密传输、通信并发性能改善、同步事件等等，并以“基础协议—通信软件—API接口”机制进行技术实现。系统主要功能特色如下：     在Internet上架构大型树状级联网     升级动态IP的Internet节点成为树状级联网节点     升级企业内网节点成为树状级联网用户     独特的节点代码和用户代码命名规则     支持对级联网中任意节点的快速寻址，并对应用程序透明     上下层节点间自动维持连接，断开后自动重建连接     智能分担根节点压力，有效利用固定IP节点的资源     UDP技术与Socket技术结合，并发性能及响应速度优异     采用小容量信息加密、大容量信息压缩机制，传输速度快     支持对任意节点内网数据库的读写，并对应用程序透明     支持内网用户间、外网节点间、用户与节点间的各种数据通信     支持信息群发，一句代码完成向成千上万的各地用户发布信息     支持业务逻辑插件的本地挂接和远程自动挂接及远程调用     支持自定义格式数据的传输，具备无限的业务扩展能力     监控功能丰富、系统稳定可靠、可无人值守运行     提供应用编程控件，应用程序接口(API)极佳     本系统与三层结构中的CORRBA、.NET、COM/DCOM等技术在实现的效果上有些类似，但编写应用程序的过程则区别较大。后者并不支持专用网的组建、分层的命名/动态IP寻址、UDP形式的连接维持等，因而在广域网上组件专用级联网并编写应用程序时，仍然需要程序员额外编写大量代码，技术难度仍然较大/较多；而使用本系统，这些问题都不再需要考虑，程序员的主要精力将更多地投放到应用逻辑的实现上，因此负担更轻。
完全同意:onemonth(CSDN真烦)
从BlueTrees(蜗牛) 的发言看，说出这么多问题，是属于还没有掌握设计的缘故，而不是分层本身的问题。
Java 为什么会有那么多设计模式，就是因为java开发不方便，如果不采用模型固定的方法，开发出来的东西效率非常底下。所有才引入了很多的模式来解决效率的问题。
============================================
老兄你太搞笑了，知道什么是无知者无畏吗？
用delphi做三层应用，可以超出局域网吗？服务端要放到一个公用Ip上吗？
Java 为什么会有那么多设计模式，就是因为java开发不方便，如果不采用模型固定的方法，开发出来的东西效率非常底下。所有才引入了很多的模式来解决效率的问题。
--------------
也算是其中一个说法
用socket，ado，tcp等来编写啦
实现远程连接的c/s,b/s混合架构
也想用delphi做三层，基于corba的。
希望牛人过来讲讲。。
另外visibroker在那里下载大家知道吗》
我发现一个问题，三层不支持API级的二次开发有点郁闷，因为客户有这个需求......
多一层就是多一层麻烦观注下一代技术WPF
SQL Server 2008提供了直接的数据持久层，在语法上数据表直接表现为class，记录行表现为class的实例。加上嵌入语言中的linQ，和编程语言结合的很平滑，查询得到的数据集具有集合特征，操纵起来很方便，linQ很不错，组合语法延迟执行，只有在真正用到数据集数据的时候才真正翻译为SQL查询执行实际的查询操作，而在语言外观上根本觉察不到。
实体之间的复杂关系，查询时如何表达一直是个难题（我自己的感受），但是有了LinQ，这些都不再是问题了。如果直接使用SQL查询，破坏了中间层漂亮的外观，不允许直接使用SQL又缺乏足够的灵活性。现在问题都得到了解决。完美的中间层一致的解决办法，我真的好想大笑啊，实在太棒了，就是性能差了一点，其他应该很棒了。
在delphi重要实现这些，难度太大了，我以前设想用纯集合操作（差并交迪卡尔积）来组合查询，数据集对象用集合操作互相组合，实际上，数据集对象并不包含真正的查询数据，在最终使用时，组合得到的最终数据集对象把这些操作关系翻译成SQL查询，得到包含实际数据的数据集对象。可惜，从没时间来实现这些东西。为生计奔忙啊。其实应该很容易，我太懒了，现在再也不用去想了，人家比我的想法更优秀更成熟。平时在用数据集对象的时候，使用filter，效率的确太低了。而中间层又不可能老是变来变去。客户端filter好像不能避免似的。