jQuery对下拉框Select操作总结

jQuery获取Select元素,并选择的Text和Value:
1. $(“#select_id”).change(function(){//code…});   //为Select添加事件,当选择其中一项时触发
2. var checkText=$(“#select_id”).find(“option:selected”).text();  //获取Select选择的Text
3. var checkValue=$(“#select_id”).val();  //获取Select选择的Value
4. var checkIndex=$(“#select_id “).get(0).selectedIndex;  //获取Select选择的索引值
5. var maxIndex=$(“#select_id option:last”).attr(“index”);  //获取Select最大的索引值
jQuery获取Select元素,并设置的 Text和Value:
实例分析:
1. $(“#select_id “).get(0).selectedIndex=1;  //设置Select索引值为1的项选中
2. $(“#select_id “).val(4);   // 设置Select的Value值为4的项选中
3. $(“#select_id option[text=’jQuery’]”).attr(“selected”, true);   //设置Select的Text值为jQuery的项选中
jQuery添加/删除Select元素的Option项:
实例分析:
1. $(“#select_id”).append(“<option value=’Value’>Text</option>”);  //为Select追加一个Option(下拉项)
2. $(“#select_id”).prepend(“<option value=’0′>请选择</option>”);  //为Select插入一个Option(第一个位置)
3. $(“#select_id option:last”).remove();  //删除Select中索引值最大Option(最后一个)
4. $(“#select_id option[index=’0′]”).remove();  //删除Select中索引值为0的Option(第一个)
5. $(“#select_id option[value=’3′]”).remove();  //删除Select中Value=’3’的Option
6. $(“#select_id option[text=’4′]”).remove();  //删除Select中Text=’4’的Option
三级分类 <select name=”thirdLevel” id=”thirdLevel”
onchange=”getFourthLevel()”>
<option value=”0″ id=”thirdOption”>
请选择三级分类
</option>
</select>
</div>
四级分类:
<select name=”fourthLevelId” id=”fourthLevelId”>
<option value=”0″ id=”fourthOption”>
请选择四级分类
</option>
</select>
</div>
.if($(“#thirdLevel”).val()!=0){
$(“#thirdLevel option[value!=0]”).remove();
}
if($(“#fourthLevelId”).val()!=0){
$(“#fourthLevelId option[value!=0]”).remove();
}//这个表示:假如我们希望当选择选择第三类时:如果第四类中有数据则删除,如果没有数据第四类的商品中的为默认值。在后面学习了AJAX技术后经常会使用到!
获取Select :
 获取select 选中的 text :
   $(“#ddlRegType”).find(“option:selected”).text();
 获取select选中的 value:
   $(“#ddlRegType “).val();
 获取select选中的索引:
     $(“#ddlRegType “).get(0).selectedIndex;
设置select:
 设置select 选中的索引:
     $(“#ddlRegType “).get(0).selectedIndex=index;//index为索引值
 设置select 选中的value:
    $(“#ddlRegType “).attr(“value”,”Normal“);
    $(“#ddlRegType “).val(“Normal”);
    $(“#ddlRegType “).get(0).value = value;
 设置select 选中的text:
var count=$(“#ddlRegType option”).length;
  for(var i=0;i<count;i++)
     {           if($(“#ddlRegType “).get(0).options[i].text == text)
        {
            $(“#ddlRegType “).get(0).options[i].selected = true;
            break;
        }
    }
$(“#select_id option[text=’jQuery’]”).attr(“selected”, true);
设置select option项:
 $(“#select_id”).append(“<option value=’Value’>Text</option>”);  //添加一项option
 $(“#select_id”).prepend(“<option value=’0′>请选择</option>”); //在前面插入一项option
 $(“#select_id option:last”).remove(); //删除索引值最大的Option
 $(“#select_id option[index=’0′]”).remove();//删除索引值为0的Option
 $(“#select_id option[value=’3′]”).remove(); //删除值为3的Option
 $(“#select_id option[text=’4′]”).remove(); //删除TEXT值为4的Option
清空 Select:
$(“#ddlRegType “).empty();
jquery获得值:
.val()
.text()
设置值
.val(‘在这里设置值’)
$(“document”).ready(function(){
$(“#btn1”).click(function(){
$(“[name=’checkbox’]”).attr(“checked”,’true’);//全选
})
$(“#btn2”).click(function(){
$(“[name=’checkbox’]”).removeAttr(“checked”);//取消全选
})
$(“#btn3”).click(function(){
$(“[name=’checkbox’]:even”).attr(“checked”,’true’);//选中所有奇数
})
$(“#btn4”).click(function(){
$(“[name=’checkbox’]”).each(function(){//反选
if($(this).attr(“checked”)){
$(this).removeAttr(“checked”);
}
else{
$(this).attr(“checked”,’true’);
}
})
})
$(“#btn5”).click(function(){//输出选中的值
var str=””;
$(“[name=’checkbox’][checked]”).each(function(){
str+=$(this).val()+”\r\n”;
//alert($(this).val());
})
alert(str);
})
})

数据库连接池Druid使用总结

根据综合性能,可靠性,稳定性,扩展性,易用性等因素替换成最优的数据库连接池。
Druid:druid-1.0.29
数据库  Mysql.5.6.17
替换目标:替换掉C3P0,用druid来替换
替换原因:
1、性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0 。hikariCP的高性能得益于最大限度的避免锁竞争。
2、druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性。
3、综合性能,扩展性等方面,可考虑使用druid或者hikariCP连接池,比较方便对jdbc接口进行监控跟踪等。
4、可开启prepareStatement缓存,对性能会有大概20%的提升。
psCache是connection私有的,所以不存在线程竞争的问题,开启pscache不会存在竞争的性能损耗。
psCache的key为prepare执行的sql和catalog等,value对应的为prepareStatement对象。开启缓存主要是减少了解析sql的开销。
5、3p0历史悠久,代码及其复杂,不利于维护。并且存在deadlock的潜在风险。
6、Druid可以打印SQL,慢查询方面的日志
Druid 参数
配置参数 缺省值 游戏服设置的值 参数说明
initialSize 0 4 初始化连接数量
minIdle 0 4 最小空闲连接数
maxActive 8 8 最大并发连接数
maxWait -1L 60000
获取连接时最大等待时间,单位毫秒。配置了maxWait之后,
缺省启用公平锁,并发效率会有所下降,
如果需要可以通过配置useUnfairLock属性为true使用非公平锁。
timeBetweenEvictionRunsMillis 60000 60000
配置间隔多久才进行一次检测,检测需要关闭的空闲连接,单位是毫秒
Destroy线程会检测连接的间隔时间
minEvictableIdleTimeMillis 1800000 1800000 配置一个连接在池中最小生存的时间,单位是毫秒
validationQuery null select 1 用来检测连接是否有效的sql,要求是一个查询语句
testOnBorrow FALSE FALSE 申请连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能。
testOnReturn FALSE FALSE 归还连接时执行validationQuery检测连接是否有效,做了这个配置会降低性能
testWhileIdle TRUE TRUE
建议配置为true,不影响性能,并且保证安全性。 申请连接的时候检测,如果
空闲时间大于 timeBetweenEvictionRunsMillis, 执行validationQuery检测连接是否有效。
poolPreparedStatements FALSE TRUE
false 是否缓存preparedStatement,也就是PSCache。
PSCache对支持游标的数据库性能提升巨大,比如说oracle。
在mysql5.5以下的版本中没有PSCache功能,建议关闭掉。
5.5及以上版本有PSCache,建议开启。
maxPoolPreparedStatementPerConnectionSize 10 100
要启用PSCache,必须配置大于0,当大于0时,
poolPreparedStatements自动触发修改为true。
单个connnection独享一个statement cache,也就是说maxOpenPreparedStatements是针对单个connection链接的
运行原理:
数据库连接池在初始化的时候会创建initialSize个连接,当有数据库操作时,会从池中取出一个连接。如果当前池中正在使用的连接数等于maxActive,则会等待一段时间,等待其他操作释放掉某一个连接,如果这个等待时间超过了maxWait,则会报错;如果当前正在使用的连接数没有达到maxActive,则判断当前是否空闲连接,如果有则直接使用空闲连接,如果没有则新建立一个连接。在连接使用完毕后,不是将其物理连接关闭,而是将其放入池中等待其他操作复用。 同时连接池内部有机制判断,如果当前的总的连接数少于miniIdle,则会建立新的空闲连接,以保证连接数得到miniIdle。如果当前连接池中某个连接在空闲了timeBetweenEvictionRunsMillis时间后仍然没有使用,则被物理性的关闭掉。有些数据库连接的时候有超时限制(mysql连接在8小时后断开),或者由于网络中断等原因,连接池的连接会出现失效的情况,这时候设置一个testWhileIdle参数为true,可以保证连接池内部定时检测连接的可用性,不可用的连接会被抛弃或者重建,最大情况的保证从连接池中得到的Connection对象是可用的。当然,为了保证绝对的可用性,你也可以使用testOnBorrow为true(即在获取Connection对象时检测其可用性),不过这样会影响性能。
如果要进行SQL监控,可以加入以下代码:
  1. Log4j2Filter log4j2 = new Log4j2Filter();
  2. log4j2.setResultSetLogEnabled(false);
  3. log4j2.setStatementSqlPrettyFormat(false);
  4. log4j2.setStatementExecutableSqlLogEnable(true);
  5. log4j2.setDataSourceLogEnabled(false);
  6. log4j2.setConnectionLogEnabled(false);
  7. log4j2.setStatementLogEnabled(false);
  8. log4j2.setResultSetLogEnabled(false);
  9. ret.setProxyFilters(Arrays.asList(log4j2));
闲置检测,创建连接,废弃连接清理由这三线程管理
Daemon Thread [Abandoned connection cleanup thread]
Daemon Thread [Druid-ConnectionPool-Create-1184124073]
Daemon Thread [Druid-ConnectionPool-Destroy-1184124073]

领域模型中的实体类分为四种类型:VO、DTO、DO、PO

经常会接触到VO,DO,DTO的概念,本文从领域建模中的实体划分和项目中的实际应用情况两个角度,对这几个概念进行简析。
得出的主要结论是:在项目应用中,VO对应于页面上需要显示的数据(表单),DO对应于数据库中存储的数据(数据表),DTO对应于除二者之外需要进行传递的数据。
一、实体类
百度百科中对于实体类的定义如下:
实体类的主要职责是存储和管理系统内部的信息,它也可以有行为,甚至很复杂的行为,但这些行为必须与它所代表的实体对象密切相关。
根据以上定义,我们可以了解到,实体类有两方面内容,存储数据和执行数据本身相关的操作。这两方面内容对应到实现上,最简单的实体类是POJO类,含有属性及属性对应的set和get方法,实体类常见的方法还有用于输出自身数据的toString方法。
二、领域模型中的实体类
领域模型中的实体类分为四种类型:VO、DTO、DO、PO,各种实体类用于不同业务层次间的交互,并会在层次内实现实体类之间的转化。
业务分层为:视图层(VIEW+ACTION),服务层(SERVICE),持久层(DAO)
相应各层间实体的传递如下图:
项目中我们并没有严格遵循这种传递关系,但这种和业务层次的关联对我们理解各实体类的作用是有帮助的。(我们没有接触到PO的原因,我理解为ORM对PO进行了封装)
以下是资料的原文,上图是基于此绘制的:
概念:
VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。
DTO(Data Transfer Object):数据传输对象,这个概念来源于J2EE的设计模式,原来的目的是为了EJB的分布式应用提供粗粒度的数据实体,以减少分布式调用的次数,从而提高分布式调用的性能和降低网络负载,但在这里,我泛指用于展示层与服务层之间的数据传输对象。
DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体。
PO(PersistentObject):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段(或若干个)就对应PO的一个(或若干个)属性。
模型:
下面以一个时序图建立简单模型来描述上述对象在三层架构应用中的位置
l 用户发出请求(可能是填写表单),表单的数据在展示层被匹配为VO。
l 展示层把VO转换为服务层对应方法所要求的DTO,传送给服务层。
l 服务层首先根据DTO的数据构造(或重建)一个DO,调用DO的业务方法完成具体业务。
l服务层把DO转换为持久层对应的PO(可以使用ORM工具,也可以不用),调用持久层的持久化方法,把PO传递给它,完成持久化操作。
l 对于一个逆向操作,如读取数据,也是用类似的方式转换和传递,略。
三、项目中的实体类
项目中常见的实体类有VO,DO和DTO,命名规则也常是以相应字符串结尾,如*VO.Java。但是DTO不总是遵循这个规则,而通常与他的用途有关,如写成*Query.java,表示存储了一个查询条件。项目中实体类出现的业务层次也没有这么严格,例如我们可以在视图层就组装一个DO,也可以将一个VO从持久层传出来,所以与业务分层相关联的划分方法显得有些冗余。从项目代码中抽象出的理解是:VO对应于页面上需要显示的数据,DO对应于数据库中存储的数据,DTO对应于除二者之外需要进行传递的数据。

SOA和微服务架构的区别

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套。在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务。
如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较重的ESB企业服务总线,同时SOA的思想进入到单个业务系统内部实现真正的组件化。
把这个核心搞清楚后,再来看下网上找到的对微服务架构的一些定义和阐述:
微服务可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称,微服务是需要与业务能力相匹配,这种说法完全正确。不幸的是,仍然意味着,如果能力模型粒度的设计是错误的,那么,我们就必须付出很多代价。如果你阅读了Fowler的整篇文章,你会发现,其中的指导建议是非常实用的。在决定将所有组件组合到一起时,开发人员需要非常确信这些组件都会有所改变,并且规模也会发生变化。服务粒度越粗,就越难以符合规定原则。服务粒度越细,就越能够灵活地降低变化和负载所带来的影响。然而,利弊之间的权衡过程是非常复杂的,我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
再强调下即:
首先对于应用本身暴露出来的服务,是和应用一起部署的,即服务本身并不单独部署,服务本身就是业务组件已有的接口能力发布和暴露出来的。了解到这点我们就看到一个关键,即我们在进行单个应用组件设计的时候,本身在组件内部就会有很大接口的设计和定义,那么这些接口我们可以根据和外部其它组件协同的需要将其发布为微服务,而如果不需要对外协同我们完全可以走内部API接口访问模式提高效率。
其次,微服务架构本身来源于互联网的思路,因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行。这个也可以看到在互联网开放能力服务平台基本都采用了Http API的方式进行服务的发布和管理。从这个角度来说,组件超外部暴露的能力才需要发布为微服务,其本身也是一种封装后的粗粒度服务。而不是将组件内部的所有业务规则和逻辑,组件本身的底层数据库CRUD操作全部朝外部发布。否则将极大的增加服务的梳理而难以进行整体服务管控和治理。
微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。
对于互联网谈到微服务架构一定会谈到Devops即开发测试和部署运维的一体化。当我们的单体应用以及拆分为多个小应用后,虽然整体架构可以松耦合和可扩展,但是如果拆分的组件越多,这些组件之间本身的集成和部署运维就越复杂。即任何一个组件,当他依赖的外部其它应用组件越多的时候,整个集成,部署和联调测试的过程就越复杂。这些如果完全靠我们手工去完成一是增加工作量,一是增加出错概率。
原来谈组件化开发谈的最多的是单个组件的持续集成,包括配置环境集成,自动打包部署,自动化的冒烟测试等。对于微服务架构下首先仍然是要做好单个组件本身的持续集成,其次在这个基础上增加了多个组件的打包部署和组件间的集成。里面的核心思想就是Devops的思路,希望能够实现开发设计到部署运维的一体化。
由于微服务架构里面强调了单个组件本身是可以在独立的进程里面运行,各个组件之间在部署的时候就能够做到进程级别的隔离。那么一台服务器我们可能需要初始化几十个甚至更多的进程来进行应用组件的部署。为了保持进程的隔离性,我们可以用虚拟机,但是当几十个进程都完全用独立的虚拟机就不现实的,而这个问题的解决刚好就是利用PaaS平台里面的轻量Docker容器来做这个事情,每个Docker是独立的容器刚好又完全做到进程级别的隔离,资源占用率又最小,这些特点刚好满足微服务架构的开发测试和自动化部署。
前面这些问题思考清楚后就是考虑所有暴露的微服务是否需要一个统一的服务管控和治理平台,按照当前微服务架构的整体思路,虽然单个服务的实现和发布仍然是在组件内部完成的,但是这些组件暴露的服务本身的调用情况,服务本身的安全,日志和流量控制等仍然需要一个统一的SOA服务管理平台来完成。
由于微服务尽量都是通过HTTP API的方式暴露出去的,因此这种服务管理平台不需要像传统企业内部的ESB服务总线这么重。但是最基本的服务注册,服务代理,服务发布,服务简单的路由,安全访问和授权,服务调用消息和日志记录这些功能还是需要具备。类似淘宝的Dubbo架构,即可以做为微服务架构下的服务管控平台。
对于这种服务管控平台,核心需要讨论的就是服务每次调用本身的消息传递,输入和输出日志是否需要记录,当前就有两种做法,一种是不记录,管理平台只负责服务注册和目录发布,安全授权,实际的服务访问仍然是两个组件之间的点对点连接完成,这种方式下整个架构下获取更高的性能,同时服务管理平台也不容易成为大并发服务访问下的单点瓶颈;另外一种方式就是完全记录,在这种方式下就需要考虑服务管理平台本身的集群化不是,高并发下的性能问题。而个人建议最好的方式还是SOA服务管理平台应该提供两种管理能力,同时仅仅对核心的需要Log日志的服务进行日志记录,而其它服务只提供服务目录和访问控制即可。