我的困惑,请大家帮忙（2）--关于数据访问层,业务层,界面层的问题
以前做信息管理系统都是所有程序写在界面层，数据访问都用象CRecordSet这类的对象来实现。现在想数据访问层，业务层，界面层分离。
我碰到的问题：
1、是否对数据库中需要维护的每张表定义一个类？或定义两个类一个STATEFUL（数据）类和STATELESS（接口）类？
2、对于修改、插入记录数据正确性的校验必须放在数据访问层，业务层，界面层中的那一层？
3、对于只是数据的维护，不涉及业务，如代码表的维护，是否界面层直接调用数据访问层的对象？
我对上面两个问题的想法：
问题1、每张表定义一个类那要定义好多类？如果我还用以前的方式，把CRecordSet当做数据层的对象，那我觉得没有实现分离，因为调用CRecordSet对象需要写SQL语句，也就是需要知道数据层的细节？
问题2、把数据检验放在界面层，把界面层做的太复杂了，而且我觉得也不是应该由界面层控制的，把数据检验放在数据访问层，那么需要定义许多数据检验失败的返回值，如插入记录时，有10个字段，必须定义10个错误返回值，表示哪个字段检验失败，程序写起来很麻烦。
Q:1、是否对数据库中需要维护的每张表定义一个类？或定义两个类一个STATEFUL（数据）类和STATELESS（接口）类？
A:不一定，这是一个对象-关系映射问题，首先你要先设计出对象模型，然后在映射为数据库设计，O-R mapping 的策略有很多。
Q:2、对于修改、插入记录数据正确性的校验必须放在数据访问层，业务层，界面层中的那一层？
A:每层都要有对数据正确性的校验。但是越早进行校验对用户来说越友好。
Q:3、对于只是数据的维护，不涉及业务，如代码表的维护，是否界面层直接调用数据访问层的对象？
A:当然可以，但是这样不好。
1.每张表需要一个entity bean,不是session bean,多少个session bean根据业务逻辑判定
2.简单校验在界面层(如数字，字符校验),复杂校验在业务层(session bean中)
3.最好通过业务层访问entity bean
一点浅见。
to LXJ2001(lxj)
从你的描述来看，你的概念不对，不是要为每张表定义一个类，而是要对类进行关系-对象映射来确定需要几张表!
首先要明白类和数据库表是两个概念，在很多情况下一个有持久化要求的类可以映射到一个数据库表上，但这不是一定的，从OO的方法而言，首先有了类，然后决定那些类需要被持久化，然後看怎么持久化，这就是O-R mapping，实现关系-对象映射有很多原则和方法，举个例子，你有一个基类“职员”，有这个类的两个派生类“校长”、“教导主任”，这样的继承关系怎么用数据库表来实现？有3种方法，各有优缺点：
1。每个类用一个表来实现，这样做可以充分体现OO中的优势，但是查找和更新都不容意，因为没查找或更新一个子类对象，都要涉及它的基类，这样要对两个表操作。
2。这三个类用一张表来实现，这样做得好初是查找方便，但不能体现OO的优势，比如要修改基类，则要修改所有子类对象中相应的字段，由于两个子类在一张表中，肯定造成冗余。
3。每个子类一张表，基类的属性分布在每个子类中，这样做有和2同样的问题（修改基类的问题），但是消灭了冗余，但是这种方法比2在统计数据方面有劣势。
具体采取哪种方法，要看实际使用的要求，比如要是很少修改基类，那么采取后两种方法比较好。
