只显示主题贴

Lucas Lee 写道你的优化方法只是泛泛的方向,没有结合具体实际来考虑是否合适。 首先你得找到瓶颈。数据库执行SQL、转化XML、其它部分各占的时间百分比,然后针对大头部分优化。 我觉得你的使用存储过程的方法实现工作量、优化效果上均不会有很好的表现。 看起来你们没有将结果集分页?这个对性能影响是挺大的。 另外,你们的硬件似乎太老了点,8年没换过硬件吧?可以考虑一下--至少加个几G内存还可以吧。 实际上,我们尝试过2种使用SQL语句的方式。一种是把一部分数据的转换也用SQL实现;一种是只用SQL语句取出原始的数据,数据转换都在服务端进行。因为数据库设计得不合理,所以需要从多个表取数,且数 ...
  • 进入论坛 Java
一、问题分析 公司目前维护的一个系统,已经有超过8年的历史。现在遇到严重的性能问题,尤其是查询方面。系统简单介绍如下: 1. 架构:客户端(windows程序)+服务端(J2EE,EJB,Web Service)+数据库(oracle); 2. 技术特点: 客户端和服务端通过Web Service进行数据传输; 服务端为传统的EJB; 服务端数据采用自行开发的DataSet进行封装,以XML格式返回给客户端; 无DAO对象与领域对象; 无数据缓存机制; 数据库设计严重违背第三范式。 查询经常要从好几个表取数,而且需要将表数据经过复杂的转换(如行列转换)才能得到目标结果,数据量较大,超过5万行 ...
  • 进入论坛 Java
tuti 写道画Color Uml的过程不就是分析吗? 我的理解中这个分析是基于前期需求分析的基础上的一个抽象、对象化过程。在需求分析过程中完成系统的功能分解、物理分解。
最近在使用Color uml和DDD方法的时候有些思考,写出来和大家一起讨论一下。 1.二者的领域对象划分存在一些相似之处,如:Color uml中的Party,Thing,Place可以对应到DDD中的实体,Description可以对应到DDD中的值对象,moment-interval差不多也可以对应到DDD的服务类。 2.对于前期需求的收集、分析都可以采用Use Case的方法; 3.Color uml和DDD似乎都是直接从需求分析阶段进行设计,扔掉了传统RUP里面的分析阶段。 4.对于Color uml里面的Role对象一直没有深入的理解清楚,似乎仅仅是对业务过程中的一种描叙, ...
这段时间在考虑一个通用的权限系统,参照了RBAC以及网友的意见,详细设计图见下面附件中的图片: 1.组织机构 组织机构的设计参考了Martin Fowler的Party模式,考虑到集团应用,分为了Company和Department类型 2.用户角色 参照RBAC模型建立了用户、角色、资源、操作、权限等模型。 关于资源我结合实际遇到的情况把它分为了2种,一种是业务模块,一种是业务服务类。业务模块由多个业务服务类组成。对于业务模块有“访问”操作,对于业务服务类有CRUD以及特定的业务功能。 对于Person和User,可以建立映射来减少重复录入。 PS:论坛好像不能直接在帖 ...
  • 进入论坛 Java
在敏捷开发过程中,关于项目进度、迭代周期的确定,下面是本人的一些理解和实践: 1.项目开始阶段根据需求功能的初始优先级估计工期,初步的安排迭代计划,估计出项目的总体进度计划; 2.在项目进行过程中,根据需求优先级的调整以及项目进展,不断的更改迭代内容、周期,进而更改项目的总体进度计划; 上面是我目前采用的方法,在项目的进行过程中,迭代、总体进度调整的比较频繁。往往最终的项目进度和开始的估计相差很大,导致最初的进度计划很不准确,参考性不强。这可能是由于我对项目组人员的开发速度总结的不够准确。 另外一种考虑是项目开始不进行整个进度的计划,只是安排首次迭代,每次迭代完成前安排下次迭代的内容,这也是 ...
其实没有用orm之前,如果系统分层比较彻底的话,也同样有这个问题。我们崇尚service层不包含数据访问的东西,包括sql语句等。这些都应该是dao层实现。但是很多查询功能都需要能够多条件任意组合查询。这个时候数dao层应该如何支撑? 我的想法是: 1.做一个比较通用的查询功能,比如设计一个参数类,查询条件通过这个参数类传递到dao层。dao负责解析; 2.就是dao层穷举这些所有可能的组合,分别为每一个组合生成一个接口方法。 看到有人在Hibernate中是使用detachedCretira来实现的。在查询端构造好detachedCretira,然后传递到dao去查询。但是这种方法违背了 ...
  • 进入论坛 Java
引用举个“值对象也会存在多个不同实例,对应到数据表中就是多条记录”的具体例子来讨论。 就拿书中的例子,那个货物运输系统。每个cargo都有其特定的delivery specification。作者认为这个specification是个值对象。
  • 进入论坛 Java
DDD一书中并没有明确的说明“值对象不需要持久化”,是我从里面的第七章的例子得出的理解,里面在设计仓储的时候只对几个聚合根实体进行了仓储设计,象Delivery Specification等值对象都没有进行仓储设计。 我也正是迷惑,或者是我没有理解清楚例子的意思。不需要标识进行区分但是存在对象的重建也应该一样需要仓储的支持。 回过头来,具体化一点,如果为值对象设计仓储,为一个值对象设计一个数据库表进行存储,那么,既然值对象本身是不进行区分的,值对象也会存在多个不同实例,对应到数据表中就是多条记录,这多个实例又如何对应到数据表中的记录呢?值对象是不需要进行标识区分的。
  • 进入论坛 Java
DDD的思想否定了我们之前建立实体类的做法,主张把原来的实体类分为实体与对象。DDD一书中的定义是: 1.“以标识作为其基本定义的对象称为实体”; 2.“如果一个对象代表了领域的某种描叙性特征,并且没有概念性的标识,我们就称之为值对象”。 但是对于二者的区别与划分我仍然没有弄清楚,我的理解是:首先,实体有唯一性的标识,定义实体的时候也只取那些可以用来标识对象,用来区分、查找、匹配对象的属性和方法,其他的都转移到其他的对象中,通常是值对象中。再者,实体是需要持久化支持的。而值对象不同,值对象没有标识,其不同的实例是不需要严格区分的,是可以被共享、重用的,也不需要持久化。 我的问题是: 1. ...
  • 进入论坛 Java
wczwcg
搜索本博客
最近加入圈子
存档
最新评论