浅谈java Map 和java Bean

  本文为个人第一篇博文，欢迎吐槽，欢迎批评！小弟弟该改就改

通过不断的编写代码，渐渐地开始理解java各种对象，今天就简述下个人对Map和Bean的联系和区分做简单分析和分享！

刚入行的时候整天会听到各种MVC，前端的，后端的，结构的，设计的，等等，当时是2010年入行，这里所说的M也就是Model也是我们今天要分享的主角之一Bean。

为了大家协同工作，我们通过Model来定义一个实体的数据原型，比如说一个教师，会有如下原型：

public class Teacher{
     private String name;
     private String sex;
     private String age;
     private String subject;
     private String level;
}

有了model 大家协同工作时就知道了老师这个数据原型中每个属性的名称，我们只需要打开这个Bean文件我们就知道每个字段的定义，而不需要去找数据库的设计人员去追问教师的级别是用什么定义的，麻烦你告诉我，我们一旦看到这个model，我们一目了然。所以model的定义就是程序开发的一个规范。既然有这么规范的，那么我们再聊聊没有规范的

话说到这，也知道我意思了，我说map是不规范的，为什么我拿map和Bean说事呢，因为map可以同样实现上面教师数据原型的定义，如下：

Map teacherMap = new HashMap();
teacherMap.put("name", "Join");
teacherMap.put("sex", "man");
teacherMap.put("age", 29)
teacherMap.put("subject","java");
teacherMap.put("level", 6);

        这里我们同样看到了一个教师Join的定义，字段和上面的model定义是完全一致的，当然Bean和Map的互相转换也是非常容易的，这里我为什么说Map不规范的，因为如果每个协作的开发人员用Map来实现一个实体的话，会常常导致我们的Map的key不统一，有的人定义教师名称直接用name，但有些开发习惯的人员喜欢用实体名称加上属性名称来定义比如tName,tSex,tAge,甚至会是teacherName或者teacher_name,这些命名都是符合命名规范的，而且大家看了这些字段再联系我们的实体教师，都会明白无论是name还是tName或者是teacherName再或者是teacher_name都能理解它表示的是教师的名称，但是用Map来定义很难让协作的开发人员统一属性的定义，Bean一旦定义，大家都必须遵守，否则会导致你的代码编译报错，因此我说Map是不规范的，但本质上和Bean是可以实现同样的业务功能。

        这么说来为什么有Bean还要有这不规范的Map呢，因为他的灵活度，在数据对接上，无论web的接口或者是jdbc的数据层的接口，如果我们用Map来接收接口返回的数据，现在基本简单业务在jdbc中也会直接使用Bean，除非是一些复杂的报表返回值会用一个List>来接收，有些同学也会说了，我们也可以用一个Bean的定义来接收报表的返回值，sql能查出来的东西不是字段都能看见么，那么动态列呢，亲。包括web接口，接口提供方不能保证返回值永远不增加字段，因为接口提供方可能并不只是提供给我们一家在使用，通常是多客户端在调用，那么用Map来处理返回值的话我们可以不去care他增加的哪些字段，我们只处理我们需要的字段就可以了。

Bean的优点，他能统一所有引用方，省去很多人为的沟通成本，大家只要一看Bean就会对字段定义一目了然，

Bean的缺点，不灵活，尤其是在现在大型集成应用中，不能处理动态列

Map的缺点，就是Bean的优点，Map的优点也正是Bean的缺点，就像两口子。

具体什么时候用Map 什么时候用Bean这个需要各位慢慢领会了！这里只能意会了。

在实际开发中Bean的定义一定是谨慎的，对业务理解到一定成熟度再去定义Bean，要考虑可扩展，否则开发人员需要为了这个垃圾的Bean定义去打很多补丁，会出现很多本不该有的逻辑判断，代码迭代会越来越难，逐渐开始怀疑入错行怀疑人生，其实是一个没有把我的设计人员带来的痛苦。与君共勉！