事物脚本模型、表模型、领域模型

其实，一开始是学JAVA的，那时知道DAO模式，坚信领域模型，以为自己会往这方面发展下去。然而阴差阳错，或者是自己的意志不够坚定，当然还有其他方面的原因,工作后做起了DOTNET。过了好久，自己始终还抱怨，为什么是一大堆的DataTable、DataSet，而不是对象？为什么不分层，或者分层不严格？为什么还在拼命的写SQL语句？如今都还记得以前学和使用JAVA的时候经常会有：Interface、Dao、Bll、Factory、Model、映射文件等等用来分层很严格的文件夹，而如今却好像已经不再是那么重要了。呵呵，还经常抱怨我们公司怎么这样，不用对象！还总认为是因为和我们公司的业务有关。后来才发现，其实原因是多方面的。我只有不到两年的工作经验，其实谈这方面应该是没有可靠的理论经验的，但是我只是想想做下笔记，相信对将来还是还有用的。

 

总的来说，这和架构，和使用的开发工具有很大关系的，架构、工具和业务往往又有着必然的联系，相互关联。

1、首先从工具上来讲，JAVA有很好的分层组件支持，表示层有Struts，控制层有Spring，数据层有Hibernate，在这只是说下比较流行的，当然其实还有其他的也比较常用的工具。DOTNET基本上使用的都是微软的开发工具，尤其是编程工具。

2、其次，相信做过DOTNET的人都写过见过，逻辑层中一堆的DataTable、DataSet，而JAVA却几乎不用，使用的都是对象。为什么？其实很简单，他们各自工具和本身类库的支持侧重点不同。使用JAVA用的一般都是关系映射，有强大ORM数据库工具做后盾支持，如果DOTNET也要使用关系映射，那无疑是给自己增加大的麻烦，增加编码开销，维护也是一件很麻烦的事。

3、这就必然会导致架构时采用的模型侧重会有所不同。

 

接下来说下三种模型，先说一点，以后再补充，毕竟经验不够。

一，事物脚本模型。这个是最简单的，但是一般不会用于有复杂逻辑的系统，具体我也不是很清楚，也没有用过。

二，表模型。也就是微软提倡的模型，也是事物脚本模型和领域模型的折中。

三，领域模型。最复杂，比较难掌握的模型，但是相对其他两种能应付最复杂的系统。