[讨论]实际case中，有两种设计方案（附图和解说），请大家来...

一、需求：
一个企业黄页系统，每个企业根据自身特点会属于不同的目录下，一个企业也会属于多个目录。
企业会有广告、产品等附加信息，每种附加信息都可能有多条，比如10个广告，3个产品等
目录系统要求做到通用，也就是说，以后可能会有新的应用，目录中管理的可能不再是企业，也许是别的什么东西。

我认为应该保持数据类的单纯性，它就相当于一个类到数据库的字段一一映射（类似于EJB中的实体类）。而且从习惯思维上：人不能自已将自己提起来。同样的习惯思维：数据类不能自己将自己删除、插入、取得（当然实现是可以实现的，但有点不伦不类－－－仅为个人感觉）

至于把delet等操作放在一个单独的工具类里，那个工具类势必是一个全局的类，或者其中的方法都是static方法，我觉得有些违背oo的原则

如果此方法没使用公有状态变量,写成static方法还是不错的. 在JDK里就有很多static.


确实,而且加东西进接口容易, 要去掉它就难了, 所以接口一定要抽象好.



一般意义来说,你的话是并没错的,但这个类比较特别---实体类. 保证一个纯数据类 是有好处的,它让你数据层很清析。在ＥＪＢ中的实体类还有Hibernate参考文档中的好多例子，都是采用这种方法。　我们不妨来深入分析一下，为什么将insert等操作放到实体类中不合适。
　　首先放在数据类中和拿到数据类外从技术上来说都是可行的。但在实体类中加操作方法会使得这个类变得臃肿，还有如果我们需要一个查询方法，这个方法能根据某个字段的值得到数据对象（如ＩＤ值），如果写在类中会是这样。
Class School(){
      Long id;
      String Name;
     
     public void insert(){....}
     public void delete(){.....}
     public School getSchool(Long id){.......}
}

　要调用这个方法getSchool我们还得new School,　那写成静态方法？也不好。总之这时你发现getSchool(Long id)放在School类中一点都不合适，因为它从概念上来说根本就不应该是一个School的方法。这样的方法还有
public List getSchools(){....}  //得到所有库中的School记录
public void delete(Long id){....} //根据ＩＤ删除School记录
public void delete(School obj){....} //根据转入对象删School记录
　　当然也许你说那就将这类方法拿出去，但将insert(),delete()保留在实体类中。可以我们反过来一想，既然要拿一部份操作类出去，不如都拿出去，好集中管理。
　　也许以上的理由还是不够充分。我是写这种实体类时，都是将操作方法拿到外面的，在实践中没发现有什么问题。不过将这方法放到里面会怎么样，关键是在编程是否感觉到了混乱和模糊呢？我没试过这个方式，所以难下结论，希望大家继续讨论。



关于这个问题，在<<Effctive JAVA>>中有详细描述。我在最近的<程序员>杂志中看到一篇C++之父的访谈，他很讨厌和饥讽这种大量的set/get的做法。不过我觉得这仅是使用习惯和统一代码风格的问题，现在的JAVA IDE，已可以很方便生成set/get方法。　　


可以说说为什么这么转变吗？

如果你的系统要能同时支持多种数据库，你会后悔将操作写在实体类中。