转：http://www.cnblogs.com/xiaozhuang/archive/2008/08/15/1268907.html
这几天园子里关于软件架构的讨论还是相当激烈，大家都想要一种能最大限度的降低各层之间依赖关系的的架构来适应变化的需求，谁都不喜欢改一点而动全身，尽量降低各层的改动产生的相互影响。
本篇我以理论和实践（源代码）两个方面和大家探讨一下我的方案，希望大家多提宝贵意见。
一、软件架构的概念问题，什么是软件的架构?我的理解是：软件的架构包括两个方面的内容，一个是软件的开发架构，一个是软件的部署架构，所谓部署架构就是指部署时的分布式，集群等设计问题；开发架构就是我们平常说的软件分层设计问题，也就是我们今天要谈的问题。
二、何谓分层？分层的方式有几种？分层也就是把一个大的软件解决方案分成多个项目进行开发，分为三种，一种是按照代码的功能层次进行分层，分为数据库访问层，业务逻辑层，UI层等，一种是按照要实现的功能模块进行分层，例如新闻管理层，博客管理层等，第三种就是把前两者结合起来进行分层：先按照代码功能划分好层次，然后再在每一层中分层成各个功能模块。
三、面向接口能够降低各层之间的依赖关系吗？还需要什么？面向接口只是把对对象的直接调用转到了对接口的调用身上，但对接口的调用也需要对象的实例化为前提，因为有对象实例化的存在，所以接口并不能屏蔽掉背后的对象来完成功能；在这种情况下，依赖注入/控制反转等概念应运而生，IOC容器出现了，它能够让对象自动实例化，并管理对象的生存空间。
四、说了这么多，到底应该怎样分？我们不妨从软件的开发过程上来考虑，做软件的都知道我们要进行需求分析，要有需求分析文档，需求分析的任务就是把客户的需求转变为对软件功能的需求，主要内容包括：软件要实现那些功能模块，每个功能模块下包含哪些业务操作，这些业务操作需要哪些页面（或者窗口）支持，这些页面大概都是什么样子的，上面都有什么？有了这些信息，我们就可以开始我们的系统设计了。
我的方案中各个项目的引用关系如下：
说明：
Web：UI层，Asp.net Web应用程序项目，提供用户界面。
UnityConfig：依赖注入配置层，类库项目，对Service层和Business层进行实现配置以提供给Web调用Service层。
Service：为Web层提供服务，类库项目，里面全是接口。
Business：商业逻辑层，通过调用DA数据访问层和Entities层来实现Service层的服务接口。类库项目。
Entities：实体层�
一、怎么将CheckBox的值存储在数据库中，即一个CheckBox被选定后，如何在数据库中表示这种选定？
首先在数据库中定义几列bit类型的数据列，用来表示某个CheckBox是否被选定，数据库中的值为true或false.
前台代码：
是否推荐：<asp:CheckBox ID="IsRecommend" runat="server" />
......
