你的位置:首页 > ASP.net教程

[ASP.net教程]原则干货存起来


关键的设计原则

在开始设计之前,思考一下关键的原则,将会帮助你创建一个最小花费、高可用性和扩展性的架构。

  • 分离关注点,将应用划分为在功能上尽可能不重复的功能点。主要的参考因素就是最小化交互,高内聚、低耦合。但是,错误的分离功能边界,可能会导致功能之间的高耦合性和复杂性,

  • 职责单一,每一个组件或者是模块应该只有一个职责或者是功能,功能要内聚。

  • 最小知识原则,一个组件或者是对象不应该知道其他组件或者对象的内部实现细节。

  • 不要重复你自己,你只需要在一个地方描述目的。例如,特殊的功能只能在一个组件中实现,在其他的组件中不应该有副本。

  • 最小化预先设计,只设计必须的内容。在一些情况,你可能需要预先设计一些内容。另外一些情况,尤其对于敏捷开发,你可以避免设计过度。如果你的应用需求是不清晰的,最好不要做大量的预先设计。

http://www.cnblogs.com/roucheng/p/wendang.html

当设计一个应用和系统的时候,软件架构的目的是通过将设计分离到不同的关注点,来最小化复杂性。例如,用户接口UI,业务处理Business Process,数据访问Data Access就代表不同的关注点。在每个关注点内部,你设计的组件应该集中的内部实现,不应该和其他的组件混淆代码。例如,UI处理组件不应该包括直接访问数据源的代码,相反,应该使用业务组件或者是数据访问组建获取数据。

但是,你还是要为你的应用做一个投入|产出决定。在某些情况,你可能需要简化结构。例如,UI直接绑定到一个结果集。通常,也要从业务的角度考虑功能的边界。下面的这些高层次的原则将会帮助你从更广的范围上考虑影响设计、实现、部署、测试和维护系统的因素。

设计

在每一层保持设计模式的一致性。在一个逻辑层的内部,组件的设计对于特殊的功能应该保持一致性。

不要在应用中复制功能。只能在一个组件中提供指定的功能,这个功能不能在其他组件中复制。这将会保持组件的内聚性,而且如果功能需要修改的话,会变得很容易。

组合优先于继承。无论在什么地方,如果需要重用代码的话,优先使用组合而不是继承,因为继承增加了父类和子类的依赖关系,限制了子类的重用,

为开发建立代码风格和命名空间。建立统一的代码风格,使用和组织有关系的有意义的命名空间。

在开发的过程中,使用QA来保证系统的质量。在开发的过程中,使用单元测试和其他QA技术,例如,依赖分析和静态代码分析。为组建和子系统定义清晰的行为和性能指标,使用自动化QA工具来保证不影响整个系统的质量。

应用分层

分离关注点。将应用分离为不同的功能,这些功能保持尽可能小的重叠。主要的好处是一个功能可以最小化和其他功能的依赖关系。另外,如果一个功能失败了,不会导致其他功能的失败,对于其他功能来说是独立的。使得应用更容易理解和设计,简化复杂系统的管理。

明确层之间是如何通信的。

使用抽象实现层之间的松散耦合。可以通过定义接口来实现。另外,还可以通过使用接口类型或者是基类定义常用的接口。

在同一层,不要混合不同类型的组件。例如,UI层不应该包含业务处理组件,相反,应该包含处理用户输入和处理用户请求的组件。

在层和组件内部保持数据格式的一致性。混乱的数据格式,将会导致系统更难实现、扩展和维护。

组件、模块和功能

一个组件和对象不应该依赖于其他组件的内部实现细节。

组件的功能不要超出范围。例如,UI处理组件不应该包含数据访问代码,或者是试图提供其他的功能。

理解组件之间是如何通信的。这需要理解应用一定要支持的部署方案。你一定要决定是否所有的组件都运行在同一个进程中?是否一定要支持跨越物理或者是进程边界的通信?还是实现消息为基础的接口?

为组件定义一个清晰的职责。

你还要考虑下面的这些横向的关注点:

日志

认证

授权

异常管理

通信。选择合适的协议,最小化网络的通信量,在网络上保护传递的敏感信息。

缓存。为了提高系统的性能和响应速度,需要确定什么应该缓存?缓存在哪里?设计缓存的时候,要考虑到web服务器场和应用服务器场的问题。

推荐:http://www.cnblogs.com/roucheng/p/chengxuyuan.html