62,041
社区成员
发帖
与我相关
我的任务
分享关于代码构架设计思想的问题(望红星钻石的出现)
随着工作的时间,编程1年多,有着自己的编程习惯,也有了自己的代码框架,问题就在这代码构架上,觉
得自己在走一些弯路,没有朝着正确的方向迈上那么一步,,现在叫我说出"什么叫面向对象",我都难以启齿,我都根
本不知道什么样的设计才叫做"面向对象",究竟"面向对象"能为我带来什么,说句自嘲的话,前些日子还在看"C#设计
模式",哼哼,简直是玷污了软件的设计现请高人指点,帮我走出这万般无赖的设计思路.
现在所有项目的设计思路如下:
数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)---->前台(与后台交互)
这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或
者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样
的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出
来,很迷惘,很伤心,总觉得自己在原地踏步,不能找到正确的方向昨晚想了很久,是不是面向对象的设计就能帮我解决以
上的这一连串的问题呢???还是另有原因???那么面向对象的程序设计究竟能给我们带来了什么???
我现在的认识就是:
与数据库的操作,无论是Insert,Update,还是Delete,Search也好,只要给你提供个接口,告诉你具体那张表,有几个字段,
你就给我Insert,Update,Delete,这个对于数据库来说,完成的就是这个任务,你只负责给我做相关的操作,面向对象的设
计是不是可以用一个通用的函数来实现与数据库的操作呢???这样的话只需要修改函数,再抽象点,将函数抽象化,只需修
改函数实现的接口就可以了呢???如果将存储过程全部替换为SQL语句,就可以达到目的,用不着每次都将项目跑一遍,那么
还用存储过程干嘛???数据执行的速度怎么能提升,项目的性能怎么得到合理的提高???
有人说过句话:当你发现你的代码每次都复制粘贴,复制粘贴的时候,你就可以考虑将它们重用,
我思路肯定是有有问题的,请大家不吝分享你们的经验,交流交流,给我提出点参考的方面,不慎感激
得自己在走一些弯路,没有朝着正确的方向迈上那么一步,,现在叫我说出"什么叫面向对象",我都难以启齿,我都根
本不知道什么样的设计才叫做"面向对象",究竟"面向对象"能为我带来什么,说句自嘲的话,前些日子还在看"C#设计
模式",哼哼,简直是玷污了软件的设计现请高人指点,帮我走出这万般无赖的设计思路.
现在所有项目的设计思路如下:
数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)---->前台(与后台交互)
这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或
者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样
的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出
来,很迷惘,很伤心,总觉得自己在原地踏步,不能找到正确的方向昨晚想了很久,是不是面向对象的设计就能帮我解决以
上的这一连串的问题呢???还是另有原因???那么面向对象的程序设计究竟能给我们带来了什么???
我现在的认识就是:
与数据库的操作,无论是Insert,Update,还是Delete,Search也好,只要给你提供个接口,告诉你具体那张表,有几个字段,
你就给我Insert,Update,Delete,这个对于数据库来说,完成的就是这个任务,你只负责给我做相关的操作,面向对象的设
计是不是可以用一个通用的函数来实现与数据库的操作呢???这样的话只需要修改函数,再抽象点,将函数抽象化,只需修
改函数实现的接口就可以了呢???如果将存储过程全部替换为SQL语句,就可以达到目的,用不着每次都将项目跑一遍,那么
还用存储过程干嘛???数据执行的速度怎么能提升,项目的性能怎么得到合理的提高???
有人说过句话:当你发现你的代码每次都复制粘贴,复制粘贴的时候,你就可以考虑将它们重用,
我思路肯定是有有问题的,请大家不吝分享你们的经验,交流交流,给我提出点参考的方面,不慎感激
...全文
请发表友善的回复…
发表回复
jenny0810 2010-03-12
- 打赏
- 举报
留名 收藏
华丽的原型 2008-06-16
- 打赏
- 举报
mark一下。
rxx 2007-05-09
- 打赏
- 举报
mark一下。
bingdian37 2007-04-25
- 打赏
- 举报
引用 拉拉叉:
现在信息化的系统中大部分的功能只是数据采集的模块，数据采集没有多少复杂的业务逻辑（如果有，那是系统没有规范好）完全可以做成通用的模块，修改表结构没有那么可怕，我建议直接把业务逻辑写在界面上，直接生成sql语句。我觉得国内现在信息化程度也就在数据采集阶段罢了，特别是手工系统信息化的那种，哪里有复杂的业务逻辑，复杂的手工他们怎么做起来的。只是我们自己用了复杂的技术搞乱了自己的思路而已。简单才是美！
我认为这个完全是可行的,常用的小型系统中,确实就是一个数据采集 与维护
再加一点其他的小功能
完全可以自动生成代码的,这个自动生成占的比例应该在80%-100%
zhulei2008 2007-04-21
- 打赏
- 举报
真的很精彩，谢谢大家
nextuser 2007-04-18
- 打赏
- 举报
1.看上面的回答很搞笑,好多人推荐一些连接,让楼主去看, 你如果知道答案就自己回答,不知道,就别回答. 只有知道而不知道如何表达或者懒得表达,就另外给个url. 或者你根本不知道看那个url能否解决问题
2. 水贴比较多,还有骂楼主水平低的人. [难怪有个牛人来csdn问了问题之后没有得到解决得出csdn无高手的结论]
3. 楼主数据库改动影响到多个层次改动的问题.我也碰到过,往往没有太好的解决办法
因为 ui ---> business --> dao ---> db ,箭头表示依赖关系.因为有依赖,所以被依赖的对象变化的时候,依赖它的往往需要变动,面向对象设计,很多理论,原则都是为了隔离变化, 很多设计模式,也是为了隔离变化. 那么为了减少代码的修改,你需要隔离变化.
a. 避免使用存储过程,实际上主流倾向于不使用存储过程,但是确实这部分对性能有特殊需要,那么使用存储过程,
在性能和可维护性发生冲突的时候，有时是无法两全的，不过大多数情况下，不需要使用存储过程。
b. 有些手段能够对变化，做到局部的隔离。 如，你使用hibernate作o/r mapping，当字段变化的时候，只需要修改映射规则
和模型类。 当然如果这个字段显示在界面，界面也要修改，如果字段出现在查询，也许dao也要修改，不过有些设计可以对字段
查询作统一处理，因此也许dao层不需要改变。
c. 如果界面具有一定的特征，可以考虑由db上的表，来生成一系列代码，包括dao,business,ui,web层java代码和jsp
appfuse 项目里面就使用了基于表利用velocity定义的模版生成代码的例子。因为代码是生成的，可以减少工作量。
代码模版是可以自己订制的。 这个我用过，还有用
但是由于很多时候，我们需要生成的代码和自己写的代码来实现逻辑，在生成代码的时候，向自己写的代码不会被替换。
d。 目前业界有MDA的开发方式，由模型驱动架构，通过模型可以生成代码，模型的更动导致代码的更动，还不影响
自己手工写的代码， 模型驱动里面模型不但包括了实体对象，还有业务规则，可以一起生成，这样工作主要在设计阶段。
这个我还在看，理解得未必准确,有些工具开始在支持它，应该还不是很成熟。
什么ibm ,borland的开发工具似乎是走这个方向，另外有 compuware optimaj，eclipse emf 似乎也有点相关。
2. 水贴比较多,还有骂楼主水平低的人. [难怪有个牛人来csdn问了问题之后没有得到解决得出csdn无高手的结论]
3. 楼主数据库改动影响到多个层次改动的问题.我也碰到过,往往没有太好的解决办法
因为 ui ---> business --> dao ---> db ,箭头表示依赖关系.因为有依赖,所以被依赖的对象变化的时候,依赖它的往往需要变动,面向对象设计,很多理论,原则都是为了隔离变化, 很多设计模式,也是为了隔离变化. 那么为了减少代码的修改,你需要隔离变化.
a. 避免使用存储过程,实际上主流倾向于不使用存储过程,但是确实这部分对性能有特殊需要,那么使用存储过程,
在性能和可维护性发生冲突的时候，有时是无法两全的，不过大多数情况下，不需要使用存储过程。
b. 有些手段能够对变化，做到局部的隔离。 如，你使用hibernate作o/r mapping，当字段变化的时候，只需要修改映射规则
和模型类。 当然如果这个字段显示在界面，界面也要修改，如果字段出现在查询，也许dao也要修改，不过有些设计可以对字段
查询作统一处理，因此也许dao层不需要改变。
c. 如果界面具有一定的特征，可以考虑由db上的表，来生成一系列代码，包括dao,business,ui,web层java代码和jsp
appfuse 项目里面就使用了基于表利用velocity定义的模版生成代码的例子。因为代码是生成的，可以减少工作量。
代码模版是可以自己订制的。 这个我用过，还有用
但是由于很多时候，我们需要生成的代码和自己写的代码来实现逻辑，在生成代码的时候，向自己写的代码不会被替换。
d。 目前业界有MDA的开发方式，由模型驱动架构，通过模型可以生成代码，模型的更动导致代码的更动，还不影响
自己手工写的代码， 模型驱动里面模型不但包括了实体对象，还有业务规则，可以一起生成，这样工作主要在设计阶段。
这个我还在看，理解得未必准确,有些工具开始在支持它，应该还不是很成熟。
什么ibm ,borland的开发工具似乎是走这个方向，另外有 compuware optimaj，eclipse emf 似乎也有点相关。
lxwin01 2007-04-18
- 打赏
- 举报
1.看上面的回答很搞笑,好多人推荐一些连接,让楼主去看, 你如果知道答案就自己回答,不知道,就别回答. 只有知道而不知道如何表达或者懒得表达,就另外给个url. 或者你根本不知道看那个url能否解决问题
-----------------------------------
1.认真看过url中的贴吗？只要是好的建议就应该多吸取。
我贴的url中这里面不仅有我的看法和建议，还有其他人的主建。
2.这里你提到hibernate作o/r mapping
你能讲下用到哪几个系统中，应用的范围和各项指标？
orm不是所有地方都需要，我建议楼主是有灵活的框架和好的扩展性。
当有一天你系统不需要orm时，你的框架仍然能够支持，只是用框架中已经有的功能少量的修改。
不但能够有配置的扩展，也可以支持在实体中定义，但实现的手段建议用插件。
4.现在工具很多，这需要我们多学习和思考，如果你还是程序员或者框架师不光是会用，而是知道原理，思想此工具的优点和缺点，如果是你会去怎么设计。
2. 水贴比较多,还有骂楼主水平低的人. [难怪有个牛人来csdn问了问题之后没有得到解决得出csdn无高手的结论]
----------------------------
观点偏激，我看不出在这里有什么贬低楼主，只有建议。
下面是我同意你提的几个观点。
1.同意你消灭以往的dao做法,因为我前段时间所做的便是如此。
2."模型驱动架构"，严重同意。
-----------------------------------
1.认真看过url中的贴吗？只要是好的建议就应该多吸取。
我贴的url中这里面不仅有我的看法和建议，还有其他人的主建。
2.这里你提到hibernate作o/r mapping
你能讲下用到哪几个系统中，应用的范围和各项指标？
orm不是所有地方都需要，我建议楼主是有灵活的框架和好的扩展性。
当有一天你系统不需要orm时，你的框架仍然能够支持，只是用框架中已经有的功能少量的修改。
不但能够有配置的扩展，也可以支持在实体中定义，但实现的手段建议用插件。
4.现在工具很多，这需要我们多学习和思考，如果你还是程序员或者框架师不光是会用，而是知道原理，思想此工具的优点和缺点，如果是你会去怎么设计。
2. 水贴比较多,还有骂楼主水平低的人. [难怪有个牛人来csdn问了问题之后没有得到解决得出csdn无高手的结论]
----------------------------
观点偏激，我看不出在这里有什么贬低楼主，只有建议。
下面是我同意你提的几个观点。
1.同意你消灭以往的dao做法,因为我前段时间所做的便是如此。
2."模型驱动架构"，严重同意。
rainv 2007-04-16
- 打赏
- 举报
感觉学会架构是程序员做软件的目标。
设计模式看了好多遍了，还是没真正看懂。
如果说架构是一个大树的主干的话，
设计模式就应该是架构的分枝吧。^-^
设计模式看了好多遍了，还是没真正看懂。
如果说架构是一个大树的主干的话，
设计模式就应该是架构的分枝吧。^-^
细细rainbow 2007-04-16
- 打赏
- 举报
留作学习
一杯不醉 2007-04-15
- 打赏
- 举报
顶一个字啊..虽然我看到不明白..
skyyun 2007-04-15
- 打赏
- 举报
学习中
xiang_li5257 2007-04-14
- 打赏
- 举报
现在所有项目的设计思路如下:
数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)---->前台(与后台交互)
这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或
者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样
的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出
来,
-----------------------------------------------------------------------------------
感觉lz根本没理解什么是三层模式呀！你找本最简单的模式来看看。你这个根本不是模式呀！
祝福楼主。
我觉得网上的文章很多的。找找看，应该没那么困惑的。
数据库---->存储过程---->类(属性和方法调用存储过程)----->后台处理(调类)---->前台(与后台交互)
这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或
者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样
的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出
来,
-----------------------------------------------------------------------------------
感觉lz根本没理解什么是三层模式呀！你找本最简单的模式来看看。你这个根本不是模式呀！
祝福楼主。
我觉得网上的文章很多的。找找看，应该没那么困惑的。
chw_csdn_chw 2007-04-14
- 打赏
- 举报
对于这个问题，只能借鉴一下别人的先进经验。从毕业工作到成为一个高手，肯定要经历一个比较漫长痛苦的菜鸟过程，我这里说得菜鸟是指相对于自己而言。
没有别得办法，只能学习－做项目－学习慢慢实践，没有3，4年的时间不够。
没有别得办法，只能学习－做项目－学习慢慢实践，没有3，4年的时间不够。
zwlippi 2007-04-14
- 打赏
- 举报
mark
JackLucifer 2007-04-14
- 打赏
- 举报
受教了
虽然没有实际做过项目
不过也有如LZ一样的疑惑
不过近来感觉自己貌似有些思路了
但还没有力主什么条例来
只是感觉抓着了头绪了
虽然没有实际做过项目
不过也有如LZ一样的疑惑
不过近来感觉自己貌似有些思路了
但还没有力主什么条例来
只是感觉抓着了头绪了
hxshanji 2007-04-13
- 打赏
- 举报
很多高手出现，学习。
mark。
mark。
mzg008 2007-04-13
- 打赏
- 举报
linlexing(拉拉叉)的 简单就是美，我顶一下！！！
写程序写那么复杂以后其他人去看都难看懂，
有时候甚至自己都不知道当时自己为什么写这么复杂！
其实越简单越好！维护啥的都方便！
写程序写那么复杂以后其他人去看都难看懂，
有时候甚至自己都不知道当时自己为什么写这么复杂！
其实越简单越好！维护啥的都方便！
eooda 2007-04-13
- 打赏
- 举报
.Net 的数据层要实现设置一个表名即可实现添加、删除、修改和查询的功能其实是很简单的事情了， 只要注意在系统中避免用Java中比较推崇的OR映射， 就算是以后增加或是删除字段，
数据层根本就不需要修改任何的代码， 而业务部分的修改是不可避免的。
至于用存储过程去做数据的录入、修改、删除实在不可取， 最多可以使用在大的数据量的查询！
数据层根本就不需要修改任何的代码， 而业务部分的修改是不可避免的。
至于用存储过程去做数据的录入、修改、删除实在不可取， 最多可以使用在大的数据量的查询！
zhulei2008 2007-04-13
- 打赏
- 举报
再次谢谢各位
wangjt18 2007-04-13
- 打赏
- 举报
up
加载更多回复（60）
