DATASNAP 毫无用处，纯粹鸡肋！

DATASNAP三层结构，是数据库访问的3层，不是mvc的3层
c/s也是指数据库访问的2层=Client/databaseServer，QQ、股票交易系统，期货交易系统是需要客户端，但不是这里所说的c/s
因为它们不会直接访问后台的数据库
数据库访问的2层是很讨厌的，仅仅是客户端需要数据库的驱动，就够恶心了
delphi的3层完全解决了这个问题
当然，delphi的3层不一定就是datasnap，asta、kbmmw等等都是
我自己也搞一套：client/Webserver

解决方案 »

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

客户端免数据库驱动，只是优点之一
客户端无须存数据库密码，也是很重要的优点
数据库服务器的端口不再暴露在公网，也是很重要的优点
数据库并发连接数大大减少，也是很有价值的优点，不过这个是与你提到的中间件、连接池基本一致
客户端无须保存sql了，sql都由应用服务程序生成、使用，也是一个优点
DATASNAP的确很不好，尤其是xe版本以后的新版datasnap效率更低了。我现在使用自己的方案来替代datasnap，当结构跟datasnap是类似的。
根本不懂楼主说的datasnap开发复杂在哪里？
不过感觉用三层确实挺麻烦的，像QQ这种的吧，大规模使用，想篡改的人那么多，必须用三层，像只是公司利用的erp，就没必要三层了
用数据库中间层，也可以屏蔽后端数据库的呀，前端连接首先要通过中间层认证，然后由中间层处理，所以，前端程序根本不需要直接跟后端的数据库和端口打交道。同时，到真正大数据多用户并发的，DATASNAP跟本派不上用场，比如中间层的连接池、复制、并发查询，自动负载均衡等，DATASNAP好像做不了什么吧。所以，DATASNAP是个花架子，没啥用。
datasnap起源于很早期的midas，往前推十几年的话，在那个时代midas还是有价值的，但我感觉宝蓝从来对midas都不是很重视，从delphi5以后基本都没什么大变化，后来互联网崛起，用户和数据量都猛增，分布式多层成为大数据处理的最好解决方案，而midas已经跟不上潮流了，到datasnap也就是换了个名字而已，现在很多专业的公司就是专门研究分布式应用，没必要纠结在datasnap上，大数据处理和数据挖掘有很多成型的解决方案。
从另一个角度看，delphi只是个开发工具，用它你可以自己开发出最好的分布式解决方案，而不是由delphi直接提供给你一个最好的解决方案。
哎，那个李维还在写什么DATASNAP书，一本接一本，从5.0 写到XE 3，把DATSSNAP写得天花乱坠，好像没有DATASNAP,用DELPHI 就没法写出大型分布式系统似的，纯粹是大忽悠呀，害人呀，我是没见李维的机会，不然的话，我可以跟它PK，根本不需要这个DATASNAP,使软件工程师浪费太多时间和精力。
简单讲就是客户端不要有SQL语句，数据库中间层解决方案能行吗？
我的client/webserver是可以的
sql在web server的应用服务程序里，可以是delphi写的isapi，也可以是php/jsp/asp/...
我造成撸猪的看法,
DataSnap只是delphi证明"我也能"的工具,但并不能证明"我也行",或者"我很行",或者"我最行".
小访问量的话,随便的三层架构都能承受,大访问量,大数据量的情况,还真没听说,或者见过用ds的案例.或许DS的最大作用就是在推广活动中:
"好大家看,我拖一个A,然后再放一个B,然后再设置C的D为E的F....."
"好了,F9,大家看,多简单,这就是DataSnap,这就是delphi,这就是三层..."
"好,散会...下次见..."或许大家可以说一说自己开发的或者见到过的,真正用于生产的,能承受一定负载压力的DataSnap应用.
实际上我没用过datasnap,我就是胡喷,哈哈,莫怪莫怪
复杂的SQL都最好写在数据库存储过程里，要写在中间层干嘛？SQL写在中间层，效率高吗？需要从后端主机，通过交换机/路由器来回传递，效率更低吧！特别有些大型分布式系统，中间层都有可能在不同的地区运行，通过INTERNET网来传输，效率就更低了，所以，SQL尽可能放在后端数据里，而不是中间层。中间层的作用是来调度、控制、分配请求等任务，而不是用来计算的，而DATASNAP却想把计算放到中间层来，是扯淡的。
SQL写在中间层，是相对于写在客户端，这样做进步了
另外，说是“写”，其实是指“发起”
即sql不能由客户端发起，而是由客户端发出应用请求，中间层根据请求再发起sql（可以是完整的sql语句，也可以是exec 存储过程的名称）
不深入了解和应用，只看个表象，全部都是垃圾，贵在于实用。Datasnap只以说只是一个模式，说它实用和易用并不为过。如何易用，如何实用，这个就不需要多说了。
首先，它解决了网络通讯问题要知道并不是所有人都对网络通讯非常了解，特别是在应用业务领域，往往技术并不是关键；
其次，有一个非常合理的结构模型，可以秀简易的就把UI、逻辑和数据清晰地分离，各部分可以非常明确的进行分工和协作，按照其规范还可以非常方便的进行替代。当然，这个世界上没有绝对简单又完美的东西，有的都是别人积累下来的成果，你如果想要一个开发工具可以非常完美的解决掉你所有的问题，那么你是谁呢？在这里，你还得认清楚自己的角色。可以这么说，几乎所有你写过的，将要写的，任何一个程序，在这个世界上都有不止一个比之更完美的替代品，只不过是因为时间、空间和人际之间的距离，即老祖宗说的“天时、地利、人和”。什么大数据量、高并发都是浮云，回头看看当初56Kbps网络、200MhzCPU、64MB内存、1G硬盘的年代并不算久远，当初的大数据量、高并发放到现在算什么？
问题在哪里？时间。我们可以看到很多同行的劣质工程，并不是说他们比我们笨，比我们懒，只不过是因为他们的时间有限。三个人日和三个人月开发的产出物，他们真正在市场上产生的价值与之并没有什么必然的联系。程序的关键就在于使用最低的投入解决掉最根本的问题，说数据量，提并发，讲质量，如果没有必要性，那么所有为之带来的投入都是浪费。
datasnap不只是数据库连接池。
他是完整意义上的基于delphi技术的应用服务器。
以JSON为数据载体，想法是很广阔的。
当然，看你怎么用它了，个人认为也还不够稳定。
自己也写过类似中间层的东西.
感觉json这东西其实如果只是取平面数据的话,
没必要使用.
而且客户端简单很多.
不要以为datasnap不能够解决所有问题就认为它一无用处。
实际上，你可以说delphi完全没必要存在，因为还有其他许多的优秀的语言。
但是如果把技术放对地方，就会发现原来你认为不值一谈的技术也可以那样的精彩。
datasnap简单易用，是个轻量级的东东。
而且在轻量级应用中，它很稳定。这是我的看法与感受。
楼主的想法代表大多数人的想法，就是用工具的时候只想着便利，完全不想着创造，DataSnap只是一个框架，谁让你非得去用它全部的功能了，你完全可以自己写一些逻辑去在DataSnap之上，你非要用绑定去实现，它效率肯定很低。可以说你根本不理解什么叫三层，三层只是一种思想，并不是一种技术，不是说哪种技术就是三层或者说你创建了Entity和DAL就叫用了三层。你真正把客户端和服务端以及数据库分离开了，就是真正的三层。效率你可以通过手工写一些代码来实现的。
自觉你是可笑至极，Datasnap增强了对客户端软件的链接控制，通过服务端形式控制了客户端对数据库的连接数，以及压力，也保证了数据的安全。业务逻辑更清晰。
这个事情牵扯到一个对数据库操作程序的理解问题，在世界上还没有数据库服务器的时候，一个程序自己就要承担起数据库服务器的作用。那时候也开始有了解决方案，慢慢有了各种数据库服务器。这时又出现了争执。业务逻辑是更多地放到客户程序里还是放在数据库服务器里。你可以说在客户程序里实现sql逻辑是多余的。因为完全可以写存储过程。但是其实数据库服务器当年也干过所谓多余的事，比如可以开发应用界面。谁对谁错，没法说。都想自己就能完全所有客户的需求。到了三层，其实楼主说的，站在数据库服务器提供商的角度是对的，由我数据库服务器提供三层架构就行了，不需要你客户端开发工具去实现三层。你客户端开发工具就做好通信链接服务就好了。可是这个思想发展下去，某一天，数据库服务器是不是还会直接，你们也不用自己做通信连接了，我也出一个技术，你们客户端，可以用各种tcp http协议链接我数据库，根本不需要数据库驱动了。这个争论没完没了的，就看谁做的更好了。
我是一个刚学习怎么做移动开发的，正准备做个小程序研究一下，不知道如何做专业的程序，想研究一下datasnap，没想到这里看到大家历经两年的讨论，真心感谢csdn能有一个让我学习的场所，更感谢各位对datasnap的讨论，现在想弱弱的问问各位，大家开发有大量用户android程序，都采用什么结构，如何实现呢？尤其程序整体结构，移动端-数据库是怎么连接，如何处理好？需要做中间层的事务连接层吗？谢谢！