摘要：
瀑布模型失败的根源1. 瀑布模型的4个错误假设瀑布模型是以4个假设为基础，并在此基础上推导出的一系列方法。但最终这4个假设都被证明是错误的。基础错误了，在基础上推导出的方法也必然是错误的。以下是瀑布模型的4个错误假设。1.1. 只要花时间，就能明确需求瀑布模型认为需求是可以在设计之前就明确的，只要通过正确的方法，就一定能够在设计前把握所有需求。而事实上，“需求唯一不变的就是‘需求永远是变化的 ’”。瀑布模型的思想是沿用传统行业的流程来指导软件工程，特别是受建筑业的影响，架构（Framework）、工程（Project）这些术语都是引用自建筑业。这样不可避免地受传统行业的“隐喻”影响，从而加大了 阅读全文
摘要：
四色原型概念辨析Jay注意，这篇文章对DESC和PPT的理解可能存在错误，请参考对照《四色原型札记（一）》中对DESC和PPT的解释。2010年3月28日凌晨。1. Description与PPT辨析1.1.DESC和PPT基础概念Description表示“描述”，更具体的说，它是“分类目录条目”... 阅读全文
摘要：
权限模型设计本权限模型是基于RBAC1模型。RBAC1的特点是Role可以继承，本权限模型仅使用了RBAC1的“受限继承关系”，即Role的继承关系是一个树结构，不允许多继承。1. IUserIUser是用户。这里的用户是指广义上的用户，不但包括员工，也包括用户组、职位等，它代表角色拥有者。2. IRoleIRole是角色。角色的作用是隔离用户和资源，避免资源直接耦合用户。2.1. IAdminRoleIAdminRole是有管理权限的角色。这类角色可以新建子角色，并且可以在本身的权限范围内给子角色分配资源。此类角色一般是分配给部门主管使用。2.2. IGeneralRoleIGeneralR 阅读全文
摘要：
并发控制1. 并发冲突当两个进程试图在同一时间修改同一数据，就会产生冲突。2. 并发控制有两种方式管理并发数据访问：乐观并发控制、悲观并发控制。这两种控制模式的区别在于，是在冲突发生前进行防止，还是在发生后采用某种方法来处理冲突。3. 悲观并发控制悲观并发模式假定系统中存在足够多的数据修改操作，以致任何确定的读操作都可能会受到由别的用户所制造的数据修改的影响。也就是说，悲观并发模式假定冲突总是会发生的。悲观并发控制是通过独占正在被读取的数据来避免冲突。但是独占数据会导致其它进程无法修改该数据，进而产生阻塞——读数据和写数据会互相阻塞。4. 乐观并发控制乐观并发模式假定系统的数据修改操作只会生产 阅读全文
摘要：
注意，【】中是后来加的批注。因为随着对DDD的深入了解，对DTO的思考也有所改变。分布式模式下，DTO层是一定需要的吗？DTO层的作用是为了隔离Domain Model：让DoMain Model的改动不会直接影响到UI；保持Domain Model的安全,不暴露业务逻辑。【最大多数情况看来，UI或者DO的改动，都不可避免地会影响对方，即使中间有DTO隔离，所以这一个理由是不成立的。至于安全问题，... 阅读全文
摘要：
悲观锁和乐观锁——《POJOs in Action》读书笔记（一）1 事务隔离事务隔离是数据库提供的功能。SQL Server通过SET TRANSACTION ISOLATION LEVEL语句设置事务隔离级别：SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }[ ; ]Read Committed是SQL Server的预设隔离等级。1.1 READ UNCOMMITTEDRead UnCommitted事务可以读取 阅读全文
摘要：
MVC和MVP的一些思考 阅读全文
摘要：
四色原型总结Jay注意，这篇文章是初学四色原型时的读书笔记，其中不乏错误。时隔一年，在实践中领悟到了四色原型的真正意义，特此修订。可以与后来写的《四色原型札记系列》参照对比。2010年3月27日零时。1.四色原型1.1.时刻-时段原型（Moment-IntervalArchetype）表示事物在某个时刻或某一段时间内发生的。使用红色表示。简写为MI。1.2.描述原型（DescriptionArchetype）表示资料类型的资源，它可以被其它原型反复使用，并为其它原型提供行为（用作方法的参数）。使用蓝色表示。简写为DESC。1.3.参与方-地点-物品原型（Part-Place-ThingArch 阅读全文
摘要：
从类模型转换到数据库表结构的思考Aaron从类模型转换到数据库表结构，或者说从UML类图转换为ER图，这个功能并不实用。为什麽呢？如果你的类模型能够完整地转换为表结构（每一个表都能找到与之相关的类，如果类之间是多对多关系，那么会增加一个中间表），那么说明你的类图是不完整的，它们仅仅抽象了领域模型的数据资源，并没有抽象出领域模型的业务行为，因为表结构只能描述静态资源，不能描述业务行为。也就是说，你的类模型是“失血模型”。我们这里不讨论“失血模型”与“充血模型”的优缺点，有兴趣的朋友可自己去javaeye上搜索。当然，你也可以认为，即使使用了充血模型，仍然可以从类模型映射为表结构。但从实际情况来看 阅读全文