随着工作的时间,编程1年多,有着自己的编程习惯,也有了自己的代码框架,问题就在这代码构架上,觉
得自己在走一些弯路,没有朝着正确的方向迈上那么一步,,现在叫我说出 "什么叫面向对象 ",我都难以启齿,我都根
本不知道什么样的设计才叫做 "面向对象 ",究竟 "面向对象 "能为我带来什么,说句自嘲的话,前些日子还在看 "C#设计
模式 ",哼哼,简直是玷污了软件的设计现请高人指点,帮我走出这万般无赖的设计思路.
现在所有项目的设计思路如下:
数据库----> 存储过程----> 类(属性和方法调用存储过程)-----> 后台处理(调类)----> 前台(与后台交互)
这很大可能上是符合三层架构的设计模式,但是什么事都是双方面的,有利就有弊,这样的一个最大的缺点就是:修改或
者添加数据库中一个字段,首先要修改存储过程,其次要修改类,然后要修改后台,最后还要修改前台,这样的流程,这样
的设计思路,简直是把项目重跑了一遍,工作量大,难维护,效率低.现阶段根据我的经验也不能拿出什么好的解决方案出
来,很迷惘,很伤心,总觉得自己在原地踏步,不能找到正确的方向昨晚想了很久,是不是面向对象的设计就能帮我解决以
上的这一连串的问题呢???还是另有原因???那么面向对象的程序设计究竟能给我们带来了什么???
我现在的认识就是:
与数据库的操作,无论是Insert,Update,还是Delete,Search也好,只要给你提供个接口,告诉你具体那张表,有几个字段,
你就给我Insert,Update,Delete,这个对于数据库来说,完成的就是这个任务,你只负责给我做相关的操作,面向对象的设
计是不是可以用一个通用的函数来实现与数据库的操作呢???这样的话只需要修改函数,再抽象点,将函数抽象化,只需修
改函数实现的接口就可以了呢???如果将存储过程全部替换为SQL语句,就可以达到目的,用不着每次都将项目跑一遍,那么
还用存储过程干嘛???数据执行的速度怎么能提升,项目的性能怎么得到合理的提高???
有人说过句话:当你发现你的代码每次都复制粘贴,复制粘贴的时候,你就可以考虑将它们重用,
我思路肯定是有有问题的,请大家不吝分享你们的经验,交流交流,给我提出点参考的方面,不慎感激
------解决方案--------------------------------------------------------
up
------解决方案--------------------------------------------------------
楼主应该 研究下
Petshop3/4
这样更清晰...
------解决方案--------------------------------------------------------
我觉得还是看项目来，不同的项目不同的架构不同的设计模式，在分层方面和驱动方式（数据驱
动和业务逻辑驱动）方面也会不同。
另外感觉你的问题比较乱，有点语无伦次的感觉。一会说设计模式一会说面向对象，一会又说存
储过程，有点凌乱
------解决方案--------------------------------------------------------
对于数据库方面的
http://community.csdn.net/Expert/topic/5349/5349356.xml?temp=.5791742
对于PetShop你可以看此贴
http://community.csdn.net/Expert/topic/5449/5449122.xml?temp=.2859156
面向对象的编程方式是从新的角度来解决问题。说白了就是为了程序能够有好的扩展性，重用性和灵活性。
如果你不满意你的系统，那么你开始重构吧,重构后你发现你原先的设计有问题，那么你可以开始重新设计的你系统。
系统前期除非你的需求十分明确，那么声明接口没什么问题。我不建议在系统开发前期就开始声明接口，你可以写抽象类，这样比较灵活，后期系统已经很明确了，那么再开始发布你的API.
网站多层(逻辑上多层)是很正常的，要尽量解藕。
------解决方案--------------------------------------------------------
设计软件的时候应该忘掉具体的某种数据库。业务逻辑中绑死了某种数据库操作，你的设计的能力就止于这种能力，再没有扩展性了。如果一定要修改你的公式，那么可以写为：
某种ORM或者ODBMS通用接口（与业务对象无关）----> 类(属性和方法调用存储过程)-----> 后台处理(调类)----> 前台(与后台交互)
其实你这类问题并不设计真正的软件工程技术的核心，它只是在起初入门的、需要“放在每一个地方都强调”的表现符号上的必须的观念。
软件工程逻辑设计蓝图根本就与底层的系统设计无关，它花很大力气在系统态模型的分析设计上。你把全部概念都搞清楚了，仍然不等于你做出了系统动态模型的设计；反之如果你做出了系统动态模型的设计，自然能够想到如何扩展静态设计蓝图来消除“从抽象到具体化”耦合。可惜，大多数只知道如何做静态模型设计的第一步，也就是简单地规定有哪些class，然后就立刻动手写程序，设计时从来不觉得抽象有什么作用。
------解决方案--------------------------------------------------------
不知道我理解的对不对，楼主似乎因为底层数据字典发生改变而影起整个架构发生的变动而烦恼
事实上，我觉得这是正常的，因为数据库并不是面向对象的，所以当字段或表结构发生改变时，影起改动是可以理解的，但我们可以使用实体类在对象与对象之间传递，这样会使改动仅发生在实体类和数据层上，可以减小改动。
再谈谈我对面向对象的理解：
在我看来，面向对象主要体现在设计阶段，你对整个业务的认识，对整个业务的抽象，当清晰的认识到业务实质后，才能设计出好的接口，实现时，各个对象实现自己的接口，在交互时，传递的信息隐藏在对象中
对于设计模式而言，个人觉得，在重构的时候用的比较多，因为我们不可以为了模式而模式
以上是我个人的一点点浅薄的看法，说错了勿怪
------解决方案--------------------------------------------------------
飘过
自认水平不够，不敢误人子弟
还有句话
鞋子小不小只有脚知道
------解决方案--------------------------------------------------------
楼主郁闷的是数据库的改动会引起整个系统的改动.
这个很正常,不然数据库改动有什么作用.
我想你需要考虑的不是三层架构的问题.而是思考自己的数据库设计为什么不能支持扩展性.
一个良好的数据库设计应该具有比较好的可扩展性.不会为了一点修改就添加删除字段.
在数据库最初设计中,可以保留一些冗余字段,留作以后扩展.
或者, "变字段为记录 "也是一种常用的方法.