如何找所谓"DAL"编程和面向对象的平衡杆
一个项目中用所谓"DAL"编程方式：当一个业务流程下来，就是用数据库执行语句一条条的流水线执行下写在一个方法里面，也就是所谓过程式开发。面向对象设计，总是以为其他对象的变化引起另外一种、某种行为的变化。他们两者的最终目的都是实现某功能。问题提也就出现了。
性能方面，在所谓"DAL"编程方式我们完全可以直接读取所需的数据，这样相对比较快些，但是不利于系统的耦合度，这样也造成数据库来处理业务流程。
但是面向对象设计呢，是以对象与对象之间的传递，（比如有时候只需要一个字段id就可以达到我的目的，干嘛还要浪费资源传整个对象去达到目的）是为了更容易理解业务流程、设计好模块间的耦合度等。
有时候很不能理解，到底什么样的编程才是这把杆？用户的体验要求快，设计人员要求维护性高。。
请大牛们给点思维。。。。
------解决方案--------------------
面向对象和面向过程 跟性能，资源，没有一点关系。
------解决方案--------------------
面向对象是一种方法，楼主要是做到大型项目时就知道它的好处了
------解决方案--------------------
DAL使用ORM工具封装行吧。
------解决方案--------------------

引用:

一个项目中用所谓"DAL"编程方式：当一个业务流程下来，就是用数据库执行语句一条条的流水线执行下写在一个方法里面，也就是所谓过程式开发。面向对象设计，总是以为其他对象的变化引起另外一种、某种行为的变化。他们两者的最终目的都是实现某功能。问题提也就出现了。
性能方面，在所谓"DAL"编程方式我们完全可以直接读取所需的数据，这样相对比较快些，但是不利于系统的耦合度，这样也造成数据库来处理业务流程。
……

谁跟你说过只能所谓数据库记录对应的所谓对象？面向对象是基于分析和设计的，跟关系数据库表有什么直接关系？比如说你给一个积木搭起来的楼房上加上一个屋顶（积木），那么你就有了积木对象、楼房对象，积木有形状、重量等属性，楼房有坐标、结构、稳定程度等属性。这就是面向对象，封装到恰当的程度，使得你在设计编写一个系统时不至于扯到什么数据库表、木屑或者泥土等无关的东西上。

我们写程序当然要尽可能少用对象，这样才能简练嘛！但是任何程序都要重构的，正确地重构的结果可能预示着你的程序可以完成更大的任务，此时你的设计就自然而然地有一些恰当的对象（类）了。

哪有为了多用对象（类）而胡乱堆砌华丽的名词儿的？这种现象只在一些学究身长出现，在一些刚刚学习八股式的概念而非常喜欢炫耀的人身上出现（你会看到某些人动不动就发布自己发明的就是一大堆没有什么实际价值的架构），在务实的程序员身上不会出现。
------解决方案--------------------
至于你说在一个进程内不同方法之间传递对象有什么“性能损耗”，它其实没有任何损耗，因为对象传递通常只是一种引用传递，而不是胡乱拷贝数据。（当然如果你使用F#等那类另类语言则要注意这个问题）

你应该首要地关注设计的必要性，而不是什么性能问题。
------解决方案--------------------
面向对象的要求并不是说一定要求你时时都把实体类传来传去的。有的时候，内存中是已经有了现成的实体类，当然可以把它传来传去而没有性能的损失。
面向对象的意思也并不是仅仅把数据库中的数据包装成实体类。它指的是一种思维方法和程序构造方法。

比如你要做一个点击率的累加。而点击率可能分布在图片对象，文章对象，还有可能是电影之类的等等。这个数据访问很简单，无非是UPDATE一下Click=Click+1,底层的实现你肯定会尽可能高效了。但是否能把它们的共同点抽象出来，实现一个累加器接口. 这个接口的作用是方便今后的扩展，比如不光要记录累加数，还要记录是谁点击的。你会不会依次找到所有的Click+1的地方，然后加一堆留痕的代码？