关于java三层架构,逻辑层的一些奇思异想,来者有分!

简单的说你的意思是POJO临时数据库化？

解决方案 »

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

也可以这么说吧,不过POJO临时数据库化只是一部分,为什么这样做呢?如果把本地数据库的功能放到后台数据库,可以减少很多麻烦,也不必导来导去,但势必增加后台数据库库的负担,特别是当程序变大之后,我之所以这样做的原因,也是从减轻后台数据库压力考虑,兄弟们快来看看呀!
我顶,我顶顶顶!照搂主的说法用面向对象数据库可以处理,关系数据库就难办了,数据库裸露出来,安全不好办,目前用XML处理简洁高效,能够满足使用了
不对啊。
你做的是桌面程序吗？
基于web的程序怎么可能让你在客户端生成一个“数据库”？
而且思考问题的思路有问题，你的业务逻辑全部是sql语句？
我想可以把业务逻辑最长变化的地方封装起来，如果一个东西什么都变，那么这个东西一定不可能存在。所以它的变化只是一点，封装这个一点就可以了。还有你的这个方法有很大的问题，把大量的数据放到本地计算机中……如果你亲爱的用户的数据是海量的呢？也全部放到用户的计算机上？如果一次取出一部分，那么如何维护数据的一致性？（你客户端的数据可能在取出的2秒钟后已经被其他人更改，你的数据已经过期了……）频繁的网络交换会引起网络的阻塞甚至瘫痪。
归根结底，你的这个方法是“远古”时代的C/S设计。数据库一台服务器，客户端频繁的对数据库进行读取写入的操作，网络几乎被搞瘫痪。
别忘记给分……
逻辑的处理，90%是修改sql，lz的想法虽然不错，治标不治本。
bu shi hen mingbai a
奇怪了。现在的三层已经把逻辑层分离的很清楚了。修改的话不过就是封装好修改的文件覆盖一下相关文件就行了。有什么复杂的???干吗还要做什么数据库又转来转去的修改什么sql?人家要的就是业务逻辑封装不给别人偷看到...你给人家客户把业务逻辑全都摆桌面了。这不是对黑客敞开大门喊:来吧,我这里饭菜好吃,随便吃吧...
按你说的修改sql你在原文件里改是改.在桌面改就不叫改了??
那你不如直接给原文件来个桌面快捷方式得了...
fireflyc(萤火虫)
eunice_zrx()
  说得都不错.
  而且楼主说的"需要修改程序逻辑时候,只需要修改本地相关sql语句即可",这种方法C/S早就实现了,并非新鲜创意. 而且,修改本地的SQL语句,就会反而感染C/S的缺点"修改或升级时必须修改或升级每一个客户端",不仅麻烦,且如有遗漏,则会产生错误.也就是维护麻烦.
   这类SQL语句,还是应该存在数据库服务器中.
theforever(碧海情天) 总结的很好
兄弟们,从你们的发言看,我的想法主要问题是:
一是数据的一致性问题,但是就这个问题来说,如果用程序来实现逻辑而不是sql语句那么你们
又是怎么样来取得数据的一致性的呢?如果在服务器端处理逻辑时候可以保证数据一致性,我也
可以保证在读取数据到本地数据库之后,保持和服务器数据库一致性,因为我们都连接同一个数据库为什么就不行呢?这个我因为是可以解决的.
二是通信堵塞,这个可能是比较刺手的问题,唯一的方法就是尽可能的较少无关的数据,还有就是打包压缩之后传送,不懂有没有其他的啦.
三是安全,这个可能很难解决唯一就是将打包xml数据加密啦.
兄弟们继续发言呀!
鼓励鼓励...我们就是该有自己的思考。即使不成熟，只要不断思考，终究会成功的。
不过你这想法，确实如上面的兄弟说的，似乎感染了C/S结构的一些弱点了。当然，一个项目或者产品最重要还是要看其本身的需求和特点需要什么样的架构。C/S结合B/S也未尝不是一种方法。
感觉向CS和BS的结合体虽然不成熟但是鼓励