.NET 应用架构指导 V2[15]

技术考虑

　　下面的原则帮助你选择适当的技术，依赖于设计的应用类型和应用的需求：

• 　　如果你需要基本的查询和参数，考虑直接使用ADO.NET的对象。
• 　　如果你需要支持复杂的数据访问方案，或者是想简化你的数据访问代码，考虑使用企业库的数据访问模块，更多信息请查看http://entlib.codeplex.com/。
• 　　如果你在已经存在数据库的情况下，创建数据驱动的web应用程序，考虑使用ASP.NET Dynamic Data。
• 　　如果你需要操作XML格式的数据，考虑使用System.Xml空间，以及下面的子空间，或者使用XLinq。
• 　　如果你使用ASP.NET创建用户界面，考虑使用datareader获取数据， 最大化提高性能。datareader提供了只读的、向前的快速处理每一行数据。
• 　　如果你访问的是SQL Server数据库，考虑使用ADO.NET 的 SqlClient命名空间来最大化提高性能。
• 　　如果你使用SQL Server 2008，考虑使用FILESTREAM来存储和访问BLOB数据。
• 　　如果你基于领域模型建立一个面向对象的数据访问层，考虑使用ORM框架，例如ADO.NET Entity Framework或者是开源的NHibernate。

　　性能考虑

　　性能包括数据访问层的设计和数据库的设计。在为了最大化吞吐量，而调优系统的时候，都应该考虑在内。可以参考下面的原则：

• 　　使用连接池。
• 　　考虑优化数据查询的分离层次。如果你建立的应用需要高吞吐量，可能会需要低级别的分离层次的特殊的数据操作，合并分离级别对于数据一致性会有负面的影响，你一定要仔细的分析。
• 　　使用批量的数据处理，减少和数据库服务器之间的往复。
• 　　对于不容易发生改变的数据，考虑使用乐观锁来降低数据库锁带来的损失。这可以避免数据库大量的锁定行，包括在锁的过程中连接一直打开。
• 　　如果使用datareader，使用排序查找以提高性能。

　　安全考虑

　　数据访问应该保护数据库免受偷取数据或者是破坏数据的类似攻击。可以参考下面的设计原则：

• 　　使用SQL Server的时候，考虑在可信的子系统模型中使用windows验证。
• 　　在配置文件中加密连接字符串，而不是使用系统或者是用户数据源名称。
• 　　在存储密码的时候，使用hash值，而不是加密密码。
• 　　出于审计的目的，要求数据访问层的调用者发送身份信息到数据访问层。
• 　　使用参数化的SQL查询，降低安全问题，减少SQL注入攻击。不要使用用户输入的数据进行字符串拼接。

　　部署考虑

　　在部署数据访问层的时候，软件架构的目标是考虑在生产环境的性能和安全问题。可以参考下面的原则：

• 　　将数据访问层和业务逻辑层部署在一个物理层，来提高性能，除非伸缩性和安全性有更高的要求。
• 　　如果你一定要支持远程的数据访问，考虑使用TCP提高性能。
• 　　考虑将数据访问层和数据库部署在不同的机器，部署在一起会很大的降低应用的性能。数据库服务的物理参数通常会根据角色进行优化，很少会和数据访问层的操作参数相匹配。

　　数据访问层的设计步骤

　　一个具有良好设计的数据访问层将会较少开发时间，在应用部署之后在维护上给予协助。下面会降到影响数据访问设计的关键，可以参考下面的步骤：

• 　　首先为数据访问层设计一个大概框架。
• 　　根据需要选择合适的实体类型。
• 　　选择数据访问层技术。
• 　　设计数据访问组件。
• 　　设计服务代理。

　　相关的设计模式

　　

分类	相关模式
General	Active Record Data Mapper Data Transfer Object Domain Model Query Object Repository Row Data Gateway Table Data Gateway Table Module
Batching	Parallel Processing Partitioning
Transactions	Capture Transaction Details Coarse Grained Lock Implicit Lock Optimistic Offline Lock Pessimistic Offline Lock Transation Script