实体类是否应该拥有行为

在我的QQ群里，有Q友谈到实体类是否应该拥有行为的话。有人说不，有人说可。争执不下，我的理解是这样的。

 

如果实体类没有行为，则该类主要用作数据传输（也就是充当DTO，D ata T ransfer O bject ）。因为在多层应用程序里，传输的一般是实体类对象及其集合。各层均需与实体类层耦合。对于某些层来说，实体类的行为是没有意义的。因为可能这些层只是想了解这些实体类的属性的值，或者用来赋这些属性值从而跨层传输它们。

 

如果实体类有行为，则该类主要用作业务处理。因为这些实体类要处理特殊的商业逻辑，比如说要不要数据校验，要不要作些业务规则或工作流程，要不要持久存储，要不要权限控制，要不要启动事务，要不要写入跟踪，要不要发布更改通知等等。此时，实体类既可以自身聚合相关的业务数据属性，也可以纯粹是个控制类，从而与数据传输类（DTO）对象交互。

 

在一般的应用程序里，二者常合二为一，即既有属性，又有行为。这主要用于将多层运行于单一进程的程序。如需跨越进程边界，该实体类就必须支持序列化，而只有数据才需要序列化，所以此时用DTO当然更加合理。因为此时实体类的行为对于关系它的某些进程来讲是毫无意义的，将这些行为排除掉，也符合面向对象的信息隐藏原则。

 

上述的实体类，都是可以跨多层引用的。还有一种只用数据访问层（DAL）的实体类，其数据属性主要与关系数据库表列一一对应。甚至外键都对应上了。这些类主查用于数据库的增、删、改、查，一般不用于数据传输。因OO的世界里没有关联，而RDB确有，所以，这些实体类对象尽是些蹩脚的OO实现。真正的OO，应该用对象间的引用或者对象集合的引用来替换关联。

 

总而言之，不管采用哪种实体类模型，主要取决于项目的时间、人力，还有开发习惯。从实用的角度来讲，这几种区别都不太大的。只是有些时候，采用某种形式的实体类模型会显得比其它的形式更加优雅，如是而已。