问一个oop和数据库的菜鸟问题.
有个问题,就是
有时感觉使用jdbc直接去数据库获取字段就能完成, 不用将其封装在实体类中.
例如, 我的数据库中记录着 终端的位置等信息, 然后我的需求是, 时刻判断他们的信息是否变化.
但是感觉不用实体类Client去封装.
在这里用 oop...都感觉有点多余了...
大家说是不...
------解决思路----------------------OOP是java的强制设计模式
认为一切都是对象
你所调用的JDBC API不也都是对象么
你觉得你的获取阶段只是一个过程
你可以包装成类的方法
像C++那样面向对象和面向过程混合编程估计你会喜欢
但是当你用过MFC之后估计比就不会这么想了，哈哈
------解决思路----------------------用Client实例描述的话，可读性好呀。要是用一个Map，别人看不懂不说，久了自己都不知道是啥。
而且你用Map或者对象的性能开销，也相差无几。数据库查询的开销主要在IO么。
题主说「时刻判断他们的信息是否变化.」，其实这种场景数据库并不是一种好的方式。特别是当终端成千上万，或者查询间隔小于5秒的情况。如果能用某种中间件，然后使用回调的方式会好很多。
------解决思路----------------------回调，你可以参考「设计模式-观察者模式」。
不知道你们跟那个公司合作到一个什么程度。
如果你们之间的数据交互只能通过数据库的形式，那么由于数据库没有提供监听机制，所以实时回调是不可能的。当然你有另一个思路，就是单独开一个采集线程，轮询将数据采集到内存，判断有更新的情况再通知给主线程。
如果你们之间的数据交互可以通过其他方式，比如「远程过程调用」，或者「Socket直接推送」等。那么回调的意思就很明显了了。
------解决思路----------------------所以说不适合用数据库呀。用数据库就没有回调这么一说。
你可以了解一下JMS规范，重点关注一下消息中间件的Topic模式。开源消息中间件ActiveMQ用起来听简单的。