博客园_I'm CY

策略

2012-02-09T09:33:00Z

策略

1. 策略的目标
参照SQL Server 的策略，以领域设计的方法确定各个业务的边界，从而抽象出业务之间交互的接口，同时也对具体业务内部进行抽象，对关键的业务方法在执行前、执行后的行为提供外部植入。

2. 策略的名词
方面
代码对象、单据对象、服务对象、仓储对象都是策略的方面。
条件
由对象的属性的表达式表达
针对目标
对象的方法,有两种情况，执行前(Before)、执行后(After)。
对象的属性
动作
当方面、条件、针对目标完全匹配时，执行的动作，动作的返回值可以是值对象也可以是一个算法。

3. 策略分类
算法策略
年假、工资计算公式等等归纳为算法策略，其特点为根据方面和条件返回一个值，没有针对目标。算法策略只是描述一个业务逻辑，一般作为被调用者。
执行策略
针对目标的方法被调用之后，将会引发策略的执行，在执行中我们可以对方对象的属性进行赋值，以及函数调用等动作。
执行的策略一旦启用将会自动附加到方面上。
验证策略
验证策略是一种特殊的执行策略，只需要配置满足的表达式即可。

4. 策略的外部对象方法协作
特殊情况下，有些业务逻辑开发过程中需要引用策略方面对象以外的方法进行赋值或判断，那么可以通过约定开发接口进行函数的调用。
例如：单据号的产生需要两个步骤，一、根据单据类型获取该类型的最大号；二、根据最大号安装指定的规则生成代码。通过在策略之外写好GetCode函数，定义个针对单据的GetNew的目标编写一个执行策略，对单据Code属性应用GetCode函数即可。

5. 总结
策略中心的最大的作用是：当两个业务之间的约束关系明确化时，为业务之间的耦合提供一个桥梁。

本文链接

编写有效的文档--通过二维表格优化思路.

2012-02-09T08:38:00Z

编写有效的文档，所谓有效是指最终用户可以快速的理解并使用。

文档的结构组织一般呈金子塔，主次分明，这一般没有异议，详细信息该如何描述？过多的文字势必增加用户的阅读负担，并且也不利于理解。一图胜千言，一个表格顶万语，在文档中引入图表可以大大增强文档的可理解能力，也就是提高有文档的有效性。

在软件开发过程中形成的文档，例如：需求文档、测试文档等更要注重图表的设计与利用。当然图表的设计也要科学合理，这个需要文档编写者多多思考。

最近在写测试用例，二维表格优化思路的感触多多，记录一下。

本文链接

关键元

2012-01-18T13:31:00Z

元是信息的维度，关键元就是关键维度了。

关键元的特征：主线、最小颗度

Employee是HR系统中的一个关键元

EveryDay：“每一日”也是一个关键元

排班、考勤等等都体现到Day，有开始、有结束。

但是从统计的角度来看，显然EveryDay更合适。

该如何组织，还得好好考虑

本文链接

新浪还是明码保存密码？

2012-01-14T12:14:00Z

它怎么知道？

本文链接

WPF listbox WrapPanel Horizontal无效的原因

2012-01-14T12:10:00Z

http://stackoverflow.com/questions/4244793/listbox-not-showing-items-horizontally-after-using-theme

<ListBox.ItemsPanel>

                <ItemsPanelTemplate>

                    <WrapPane Orientation="Horizontal"l></WrapPanel>

                </ItemsPanelTemplate>

            </ListBox.ItemsPanel>

无法正常横向显示,原因应用了Theme,修改对应的Theml.xaml

<ControlTemplate TargetType="{x:Type ListBox}">
    <Grid>
        <Border x:Name="Border" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" CornerRadius="2" Background="{DynamicResource ControlBackgroundBrush}" />
        <ScrollViewer Margin="1" Style="{DynamicResource NuclearScrollViewer}" Focusable="false" Background="{x:Null}">
            <StackPanel Margin="1,1,1,1" IsItemsHost="true" />
        </ScrollViewer>
    </Grid>

修改 StackPanel to an ItemsPresenter:

<ItemsPresenter Margin="1,1,1,1"/>

本文链接

webForm 页面中使用session要注意的事项

2012-01-05T14:05:00Z

在最近的项目中，为了方便使用于是在Page的构造函数中使用了session,却发现session总是为null,这是因为在构造函数中，asp.net的处理机制Session还没有构造出来，所以异常。

将处理程序移到Form_Load中，问题解决。

本文链接

2012

2012-01-01T11:49:00Z

2012就这么来了，2011就这么走了

开始新一个轮回

本文链接

名正言顺

2011-11-17T03:19:00Z

《重构》里面提到的小方法
编程里面的接口，对象
领域模型的各种概念

大到社会的各个地方，都有名字，《有关部门》只所有神秘、复杂，不就是因为太抽象了嘛

你给我一个名字，我给你一个思路------编程从命名开始

本文链接

OrderId改如何选择？

2011-09-08T05:48:00Z

OrderId排序字段，最近包括以前用到的项目都是int类型，一直没什么感受，昨天的项目确实感到用int类型那是相当的不方便。

排序的时候我们一般按照一定的模式进行编排，这个模式很象树状结构，想想部门列表其实就是这个样子了。一般情况下我们不需要注意什么，但是当记录很多，时不时需要插入一些排在前面的信息时，用Int类型如果提前编排好还行，如果编排不好，要用的编号被占用，那就有够处理。

用Numeric类型(decimal,double等),用好小数位，问题迎刃而解。

本文链接

《软件架构师应该知道的97件事》

2011-09-02T08:48:00Z

http://blog.csdn.net/jpr1990/article/details/6743033

本书译者SeanBV（他的CSDN博客）整理，推荐给大家。

1． 客户需求重于个人简历（ Nitin Borwankar ）

客户需求至上。为了自己的简历更炫而采用新技术是沽名钓誉，往往事与愿违。

2． 简化根本复杂性，消除偶发复杂性（ Neal Ford ）

分析问题好比拨云见月、水落石出。

3． 关键问题可能不是出在技术上（ Mark Ramm ）

团队同心，其利断金。

4． 以沟通为中心，坚持简明清晰的表达方式和开明的领导风格（ Mark Richards ）

沟通应当言简意赅、详略得当，别拖泥带水。

5． 架构决定性能（ Randy Stafford ）

种瓜得瓜，种豆得豆，架构设计也是一样道理。

6． 分析客户需求背后的意义 （ Einar Landre ）

抽丝剥茧，洞见症结。不要被表面需求迷惑。

7． 起立发言（ Udi Dahan ）

起立发言效果更好。

8． 故障终究会发生（ Michael Nygard ）

应该提前设计预防措施，限制故障。

9． 我们常常忽略了自己在谈判（ Michael Nygard ）

工程师应该适时转换角色，学习谈判的技巧。

10． 量化需求（ Keith Braithwaite ）

没有规矩，不成方圆。

11． 一行代码比五百行架构说明更有价值（ Allison Randal ）

可工作的代码才是目标，设计只是达成目标手段。

12． 不存在放之四海皆准的解决方案（ Randy Stafford ）

软件世界没有万能钥匙。

13． 提前关注性能问题（ Rebecca Parsons ）

尽早展开性能测试。

14． 架构设计要平衡兼顾多方需求（ Randy Stafford ）

平衡兼顾项目的技术需求和相关各方的业务需求。

15． 草率提交任务是不负责任的行为（ Niclas Nilsson ）

要设法杜绝开发人员草率提交任务的念头。

16． 不要在一棵树上吊死（ Keith Braithwaite ）

为客户提供多样化的解决方案。

17． 业务目标至上 （ Dave Muirhead ）

技术决策不能脱离业务目标和现实条件的约束。

18． 先确保解决方案简单可用，再考虑通用性和复用性（ Kevlin Henney ）

19． 架构师应该亲历亲为 （ John Davies ）

身先士卒才能赢得同事的信任。

20． 持续集成 （ David Bartlett ）

21． 避免进度调整失误 （ Norman Carnovale ）

不惜一切代价拒绝调整项目进度的要求。

22． 取舍的艺术（ Mark Richards ）

架构不可能满足所有需求。

23． 打造数据库堡垒（ Dan Chak ）

一开始就要定义好数据模型。

24． 重视不确定性（ Kevlin Henney ）

推迟决策，建设性地利用不确定性。

25． 不要轻易放过不起眼的问题 （ Dave Quick ）

别忘了温水煮青蛙的故事。

26． 让大家学会复用（ Jeremy Meyer ）

重复利用已有资源，首先要改变大家的观念。

27． 架构里没有大写的“I ” （ Dave Quick ）

变让自己变成自大狂。

28． 使用“ 一千英尺高” 的视图（ Erik Doernenburg ）

选择合适的架构视图。

29． 先尝试后决策（ Erik Doernenburg ）

30． 掌握业务领域知识（ Mark Richards ）

31． 程序设计是一种设计 （ Einar Landre ）

软件开发也分成设计和生产两个阶段。

32． 让开发人员自己做主 （ Philip Nelson ）

33． 时间改变一切 （ Philip Nelson ）

选择值得投入精力的工作，别跟以前的工作过不去。

34． 设立软件架构专业为时尚早 （ Barry Hawkins ）

35． 控制项目规模 （ Dave Quick ）

36． 架构师不是演员，是管家 （ Barry Hawkins ）

别忘了你的工作责任。

37． 软件架构的道德责任（ Michael Nygard ）

架构师的决定会影响许多人，务必慎重。

38． 摩天大厦不可伸缩（ Michael Nygard ）

但软件可以。

39． 混合开发的时代已经来临（ Edward Garson ）

40． 性能至上 （Craig Russell ）

41． 留意架构图里的空白区域（ Michael Nygard ）

空白区域“充满”了各种软件和“硬件”。

42． 学习软件专业的行话（ Mark Richards ）

同行之间讲行话方便交流。

43． 具体情境决定一切（ Edward Garson ）

44． 侏儒、精灵、巫师和国王（ Evan Cofsky ）

开发团队不应该同质化。

45． 向建筑师学习（ Keith Braithwaite ）

借鉴建筑行业的经验。

46． 避免重复（ Niclas Nilsson ）

47． 欢迎来到现实世界（ Gregor Hohpe ）

现实世界比软件世界复杂。

48． 仔细观察，别试图控制一切（ Gregor Hohpe ）

49． 架构师好比两面神 （ David Bartlett ）

架构师应该像两面神一样，眼观六路、耳听八方。

50． 架构师应关注边界和接口 （ Einar Landre ）

寻找自然的边界，分而治之。

51． 助力开发团队（ Timothy High ）

优秀团队是成功的保障，要尽量助力开发团队。

52． 记录决策理由（ Timothy High ）

记录架构决策背后的理由，具有极高的投资回报价值。

53． 挑战假设, 尤其是你自己的（ Timothy High ）

臆断是事情搞砸的主要根源。务必要确保软件基石坚实可靠。

54． 分享知识和经验（ Paul W. Homer ）

帮助周围的人不断改善，他们也会帮助我们发挥出全部的潜力。

55． 模式病 （ Chad La Vigne ）

不要让一展设计模式功力的欲望，遮蔽了务实的真知。

56． 不要滥用架构隐喻 （ David Ing ）

不要耽溺于系统隐喻之中，反让它拖了后腿。

57． 关注应用程序的支持和维护 （ Mncedisi Kasper ）

应用程序的支持和维护，永远都不应该是事后才考虑的事情。

58． 有舍才有得（ Bill de hÓra ）

珍惜需要权衡的时机，远胜毫无约束和限制。

59． 原则、公理和类比胜于个人意见和口味（ Michael Harmer ）

60． 从“ 可行走骨架” 开始开发应用（ Clint Shank ）

从“ 可行走骨架” 开始，增量培育系统成长。

61． 数据是核心（ Paul W. Homer ）

从“数据是核心”这个角度去认识系统，能大大降低理解复杂度。

62． 确保简单问题有简单的解 （Chad La Vigne ）

63． 架构师首先是开发人员 （Mike Brown ）

碰到麻烦时，架构师可不能只会干吹烟圈却束手无策。

64． 根据投资回报率（ROI ）进行决策（ George Malamidis ）

65． 一切软件系统都是遗留系统（ Dave Anderson ）

软件很快便会过时，修改维护无可避免。

66． 起码要有两个可选解决方案（ Timothy High ）

67． 理解变化的影响（ Doug Crawford ）

清楚认识变化类型及其影响。

68． 你不能不了解硬件（ Kamal Wickramanayake ）

硬件容量规划，是和软件架构同等重要的事情。

69． 现在走捷径，将来需付息（ Scot Mcphee ）

及时还清技术债务。

70． 不要追求“完美”，“足够好”就行（ Greg Nyberg ）

避免过度设计。

71． 小心“好主意” （ Greg Nyberg ）

72． 内容为王（ Zubin Wadia ）

73． 对商业方，架构师要避免愤世嫉俗（ Chad La Vigne ）

74． 拉伸关键维度，发现设计中的不足（ Stephen Jones ）

75． 架构师要以自己的编程能力为依托（ Mike Brown ）

76． 命名要恰如其分（ Sam Gardiner ）

弄清楚要做的究竟是什么。

77． 稳定的问题可以获得高质量的解决方案（ Sam Gardiner ）

78． 天道酬勤（ Brian Hart ）

真正做好那些看似简单的任务，坚守承诺。

79． 对决策负责（ Yi Zhou ）

80． 弃聪明，求质朴（ Eben Hewitt ）

81． 精心选择有效技术，绝不轻易抛弃（ Chad La Vigne ）

82． 客户的客户才是你的客户！（ Eben Hewitt ）

83． 事物发展总会出人意料（ Peter Gillard-Moss ）

设计是在不断变化的世界中持续进行探索试验的过程。

84． 选择彼此间能和谐共处的框架（ Eric Hawthorne ）

当心“无所不能”型的框架。

85． 着重强调项目的商业价值（ Yi Zhou ）

86． 不仅仅只控制代码，也要控制数据（ Chad La Vigne ）

87． 偿还技术债务（ Burkhardt Hufnagel ）

在速度和架构间进行权衡，保持平衡。

88． 不要急于求解（ Eben Hewitt ）

首先看看是否可以改变问题。

89． 打造称手的系统（ Keith Braithwaite ）

90． 找到并留住富有激情的问题解决者（ Chad La Vigne ）

91． 软件并非真实的存在（ Chad La Vigne ）

虚拟世界中的软件是柔韧可变的。

92． 学习新语言（ Burkhardt Hufnagel ）

防止沟通不畅和误解。

93． 没有永不过时的解决方案（ Richard Monson-Haefel ）

94． 用户接受度问题（ Norman Carnovale ）

减轻用户接受度问题带来的风险。

95． 清汤的重要启示（ Eben Hewitt ）

软件架构设计需要不断的精炼浓缩。

96． 对最终用户而言，界面就是系统（ Vinayak Hegde ）

97． 优秀软件不是构建出来的，而是培育起来的（ Bill de hÓra ）

这本书是开源的，大家可以到这里查看书的所有原文内容：

http://97things.oreilly.com/wiki/index.php/97_Things_Every_Software_Architect_Should_Know_-_The_Book

本文链接