之前的帖子简单分析了我想表达的意思 ,地址为 http://bbs.csdn.net/topics/391844912
无奈文笔有限加上时间匆忙，可能表达的不够详细。近几日把思路理了一下，拿出来和大家分享一下。
目前的web开发基本上是： 映射数据库的表 ，执行一些数据库操作，进行业务逻辑处理，收集页面参数信息，将结果返还给页面。虽然我们的开发流程和使用框架不同，导致我们的过程不一样，但实际上我们最终得到的结果是同样的。
而在这个过程之中，因人而异，导致追求这些结果的效率又快又慢，质量有好有坏。而这些过程是枯燥的，是乏味的。如果我们能统一出一个标准，或者约定好一些开发“规则”，减少配置，减少不必要的代码，更加专注 业务，效率，而不是如同机器般的，如流水线一样的反复去做一些没有技术含量的活，也许我们才能真正体验到编程的快乐，才能慢慢的把编程从一个工作的定位，转变为一个爱好 ，一个兴趣。 通过编程去解决一些实实在在 存在于生活中的一些问题，在满足别人的同时，自己也得到了快乐。
在日常的web开发中， 实际上我们需要做的大部分是一件事：接收页面参数，操作数据库，把结果返回给页面。实际上这是一件很简单的事，至少大部分情况下没有我们想象的那么复杂。【 有的同学可能会发问了，有些业务逻辑是很复杂的！】，然而这个世界上再复杂的事，也是由若干个简单的事组成再一起的，只要逐个击破，分析 清楚他们之间存在的关系，化繁为简，实际上也是手到擒来的事。
之前提出了使用map替代实体的思路,得到了大家的很多意见。可能因为我没表达清楚，让大家有了一些误解。并非使用原生的map去替代实体，而是对map进行一次封装，称为entityMap。这个entityMap 有什么特别的呢？即再创建的时候需指定表名，指定了表名后即可拥有当前表的一些源信息，如字段，注释，长度，字段类型等。当我们拥有了这些信息的时候，实际上再set 和 get的时候就以及拥有了很多玩法, 比如字段后台校验，自动转换为对应类型，把注释作为当前字段所属的表单或者表格的 中文等等，只要肯动脑，光是这一块实际上就有很多封装，甚至只要结合优良的设计，再页面出来的那一瞬间，通过简单的页面配置，一个模块就可以完成（实际上我已经基于extjs做了这个封装，并且投入到了生产中，用了三年了，开发效率还可以，也做了大概20多个项目，平均表数量大概120个左右的样子吧） 。
另外再说说关于entityMap的记忆问题，实体写成属性和方法之后，拥有编译器提供的自动补全提示功能，没有记忆障碍，但是
map 则需要对应一些文档或者数据库信息去看。我们首先需要达成一点共识：实体是作为数据参数的载体存在的，而并非只是单单为了把数据库中的表和程序对应而存在的。达成以上原则 ，我们来看一下，一个简单的例子：
一个用户管理的后台代码（简单演示一下）
实体版 ：
添加和修改： dao.save( user ); //有ID为修改，没ID为添加
删除： dao.delete(user); 或者 dao.delete(User.class,id);
查询 ： dao.find(User.class,....) ;
entityMap 版：
添加和修改： dao.save( userMap ); //有ID为修改，没ID为添加
删除： dao.delete(userMap); 或者 dao.delete("tableName",id);
查询 ： dao.find("tableName"....) ;
这是一个很简单的例子，并且不存在记忆障碍的问题，因为我们并没有接触到具体的字段。 我们的字段记忆障碍问题存在于字段是我们输入的字符串，实际上这即是优势之处，也是不足之处。 好就好在我们的字段是灵活的，随时可以更改，符合了现在互联网快速变更和迭代的思路，坏就坏在没有类型和编译器提示的优势。
我们分析一个业务： 比如一个订单管理，完成一个下单的功能可能涉及到 20张表，那么我们是把这20个张表的实体拿过来一起参与业务呢，还是单独再创建一个 实体，作为支撑这个下单业务的载体来的合适？
如果你说你要拿 20个表的实体参与业务逻辑，那么 我只能选择死亡。
一个正常人一定会根据这个业务的具体逻辑特性和参数特性 ，去封装一个针对这个业务逻辑数据的实体。而我们要做的，只是把这20个表里，每个表里的某几个字段拿出来对这个业务逻辑数据的实体进行填充即可。 这样以来，我们既把记忆问题规避到了最小，又可以发挥编译器的优势，何乐而不为？
最终我总结一下： 我们利用一张表里的数据完成业务时，大部分情况下只需要几个字段，我们针对性的去取，抛开繁琐的get和set，抛开这些不灵活，然后结合 实体的强类型优势，去映射业务实体，而不是数据库实体。
最终结论：
entityMap 作为数据表结构映射。 而 实体 作为业务特性参数映射。两者结合再一起，简单业务entityMap 搞定，复杂业务
entityMap作为数据表结构映射为 业务特性参数映射实体提供表字段信息。 让我们告别数据库实体映射类，告别枯燥和乏味。
PS：感谢版主顶上了首页。其实一开始我只是想简单表达一下自己的思想，万万没想到呀。 我会继续按照这个思路完善下去，不会轻易的狗带。
------解决思路----------------------
这是比较常规的MVC的Web项目前端开发，现在更多会关注后端技术，比如共享缓存，消息队列，RPC远程调用等
------解决思路----------------------
这个世界上再复杂的事，也是由若干个简单的事组成再一起的，只要逐个击破，分析 清楚他们之间存在的关系，化繁为简，实际上也是手到擒来的事 这句话说的好
但是我有几个疑问：
1、entityMap 跟实体有何区别，在你这文章中还是没太明白，从添删改操作中感觉差不多，你说做业务操作不需要全部实体，只需要部分字段，这个我理解，但是你的数据总要保存的吧？ 表的存在不就是保存数据么？ 你封装的entityMap我是不是可以理解为一个封装的BO对象呢
2、实际上我已经基于extjs做了这个封装，并且投入到了生产中，用了三年了，开发效率还可以，也做了大概20多个项目，平均表数量大概120个左右的样子吧
能有一个示例项目么？ 我很感兴趣，想学习下
3、对于你提出的entityMap我觉得还是得有点悬，就是说有点空荡，希望你能有实际例子来说明。作为程序员你懂的..最好整理一下：entityMap比较实体有何优缺点，怎样操作，还有实际使用情况如何
这只是我的想法，参考参考
------解决思路----------------------
沙发 看看 大神们前来围观------解决思路----------------------
同学，你应该参考一下.net 的dataset及typed dataset
------解决思路----------------------
围观大神，膜拜中！
------解决思路----------------------
有些道理
------解决思路----------------------
