关于OO的几个问题

    最初接触的就是结构化的程序设计方法，按照事情发生的步骤一步一步的分析，从而得到结果，在广大的OO呼声之中也开始考虑使用OO的方法来进行一些设计和实践，但是总是很困惑的使用一些东西

 

    天天都有人喊着分层，为什么要进行分层，不分层我也能够写出符合需求的代码？天天有人说着要用类来进行设计和coding，与我们以前的方法有什么本质的区别？在进行需求分析的时候，我想的第一步就是进行数据库的设计，设计好数据库就开始进行代码的编写，这是否符合OO的思想和原则呢？

 

    在开始的项目之中，并不明白OO的方法和使用原则，在编写代码的时候就直接对在aspx.cs中写入了SQL语句，数据库中的一个表就是一个实体类，最终在做到最后的时候，发现项目结构非常混乱，逻辑不清楚，当做完一个项目之后，出错了就到处去修改，在整个项目之中寻找需要修改之处，而且对整个项目的运行完全没有信心；在修改数据库表结构的时候，随便增加一个字段，就需要一个非常大的改动，首先需要修改的就是实体类，实体类改完之后，就要找到相关的使用这个实体类的地方进行相应的修改，并且得找到一些使用这个表结构的SQL语句，最终导致的就是人非常累并且随着项目时间的延长，越来越没有信心做下去

 

   随着时间的推移，好像逐步的了解了一些OO的原则

 

   在项目开始的时候，我们需要的真是业务如何进行的么？我们需要的真是业务流程的走向么？我们需要的真是数据库的设计么？好像不是的，OO的一个好处是在面对复杂业务的时候，好处不仅仅在于封装，继承，代码的服用，而真正的用处在于项目的管理，为什么项目要分层，为什么要使用类，好像都是出于这个目的，我们要做的是满足客户的需求，而不是为了单纯的数据而去保存修改数据，从而在一开始的时候或许我们就错了，我们不应该开始想的就是业务流程的走向和数据库的设计，我们开始需要的是在项目中有哪些人，需要做哪些事，做这些事的规则是什么，这些事情导致的后果又是什么？从而可以顺其自然的将数据库设计出来，并且与此同时我们设计数据库的时候，可以分离业务逻辑和控制逻辑，从而真正达到一个OO的目标

   还有一些问题没有想通，就是为什么要使用这个类的这些方法，并且将这些方法必须封装在这个类之中

 

   还有就是在需求出来之后，我们的类这个里面包括的一些数据，如何映射到数据库表之中，如何来组装这个类也就是这个对象

 

 

  目前我只能做到的就是首先将SQL语句有关数据方面的代码进行整合，集中放在一个，然后逻辑控制类代码来调用相关的SQL语句，而数据库方面则任然是一个数据库对应一个实体类，还未找到更好的解决方法

 

  希望有人对这个深入了解的指导，谢谢