xjman的专栏

摘录自“.NET 经典范例Duwamish7 大剖析”（郝 刚）“…在Duwamish7中，业务数据表示的问题是由业务实体层负责解决的。业务实体层包含用于各层间传递信息的数据集。根据需求分析结果，每个业务实体将模型化数据库中的特定信息，并选择适当的方式建立不同的业务实体。业务实体层的构建是应用程序的基础，除去SystemFramework项目外，其他层都要用到业务实体层。…使用.N

通过对网站的业务外观层和业务规则层分析发现，业务外观的包装存在问题：在对待同一个领域对象存在一个查询的业务外观对象和一个插入和更新的业务外观对象。这样做的是因为没有进行统一的业务建模还是有特别的考虑？如果把一个领域对象所有业务逻辑放在一个业务外观对象内部，那么象查询这样的方法是会被众多领域对象使用，而讲插入和修改这样的方法也一起放在这个业务外观对象中暴露给其他业务对象使用是不是不合理呢? 查询是被

基本概括了Web项目的主要功能，开始自己亲手构件代码，对于没有怎么写过很多Web代码的我来讲，了解的同时也是学习。一直很疑惑为什么Jim Conallen的那本《Building Web Applications with UML Second Edition》提供的示例工程链接已经“404 Error：Page Not Found”，在使用了Rational XDE 以后明白了身为Rationa

项目已有的架构是源于微软的经典企业应用范例：Duwamish7,因此相信这样的架构应该是适合我们目前的业务规模，但是为什么在实际应用中项目还是出现了代码重复，逻辑混乱，维护困难呢？我想很大的因素是对Duwamish架构的思想没有很好的理解，而只是在工程的形式上照搬了，加之开发的功能之间没有进行统一的抽象（因为功能需求是一点点提出的，往往是一个功能开发好了，过一段时间另一个需求会提出来），结果就像是

代码中的ViewSate或者是基类中的Session设置，类似于windows编程中的全局变量，但是Web Application复杂的在于每个Application要考虑不同的Session之间的状态传递。因此，对Session以及ViewSate变量在Page和Module之间的共享要进行详细分析。对应代码的重构是需要小组人员一起讨论代码的“bad small”的，特别是类似“PageBase

今天和沈讨论了一会对网站重构的想法，他提出的我对网站重构的目标的问题，我还没有很好的考虑过。网站的重构涉及：1）代码函数级的整理是简单的对代码进行熟悉的方法；2）网站架构重构，在目前基于Duwamish的架构的基础是不适合进行大量的重构的。因此，我们把重构的目标定位在对代码的简单整理，熟悉代码。下一阶段，再进行复杂的重构。架构本身并没有太大的问题（至少适合目前的应用），但是由于代码开发的混乱结果“

Robert C. Martin的“Agile Software Development：Principles，patterns，Practices”中关于Template Method模式和Strategy模式的比较。 1．  书中给出了一个滥用Template Method模式的例子，并不是Template Method模式本身不好，而是由于冒泡排序这个算法放在基类里实现，由其派生类实

目前网站系统问题，可以采用Robert C. Martin的“敏捷…”一书中提及的“腐化软件的气味”来分析：僵化性、脆弱性、牢固性、粘滞性、不必要的复杂、不必要的重复、晦涩性。网站的搜索功能变化很多也将会进一步变化，Strategy模式是否可以用来组织系统的这个行为呢？“当准备在一个系统中里使用策略模式时，首先必须找到需要包装的算法，看看算法是否可以从环境中分割开来，最后再考察这些算法是否会在

昨天下午和沈讨论过一次网站的整理中的问题，我向他提出了一个整理中的问题：在整理BusinessFacade层的对象时，我发现对同一个领域对象的查询、插入和更新的操作是分别放在了几个类中的，是不是要考虑把他们合并到一个BusinessFacade层的对象中呢？他给我的分析对我很有启发：BusinessFacade是封装业务逻辑的（对表现层的调用者称为业务外观层），那么业务逻辑不是CRUD（增删查