.net架构
最常用的架构是三层架构。
1. UI Tier（User Interface, 用户接口层)
表达层完成向用户展示界面，提供进一步操作的“驱动接口”，如按钮，并展示结果。
2. Business Tier（商业层）
完成数据处理，向表达层或数据层提供处理后的数据。它也可以分为 BLL(Business Logic Layer, 商业逻辑)和DAL(Data Access Layer, 数据访问)。DAL负责访问数据，BLL负责操作DAL层，操作和操作数据。BLL还负责响应表达层的事件。
3. Data Tier（数据层）
完成数据存储功能。可能是数据库、数据源、XML、文本文件等。
这样就把 数据、业务、展示 分开。UI层只负责向用户展示。至于数据如何处理和操作，BLL将进行和响应。处理后的数据如何访问DAL层，数据如何存在。介质上的数据由DATA层完成，DAL无需担心。每层之间相对独立，物理依靠性不高。有时只需编译更改后的层。
一般来说，对于开发和设计师来说，只需要UI， BLL, DAL 设计开发，DATA Tier由OS或DBMS进行，您只需按“格式”存取数据即可。
“三层结构的程序并不意味着将项目分为DAL， BLL, WebUI三个模块喊三层， 以下问题在您的项目中：
1. UILayer中只有少量SQL语句或存储过程调用， 这些句子保证数据不会被修改
2. 若取下UILayer， 您的项目还能在Interface/API层面提供所有功能吗？
3. 你的DAL可以移植到其他类似环境的项目吗？
4. 三个模块, 不同的服务器可以单独运行吗？
假如不是所有的答案都是YES， 那么你的项目不能算是严厉意义上的三层程序. 三层程序有一些规则需要遵守：
1. 最要害的, UI层只能用作外壳， Bizlogic不能包含任何处理过程
2. 设计应从BLL开始， 而不是从UI开始. 所有Bizlogic都应该在API上实现BLL层， 以面向对象的方式
3. 无论数据层是简单的SqlHelper， 还是有Mapping的Classes， 系统应该在一定程度上与抽象无关
4. 无论使用COM+(Enterprise Service), 还是Remoting， 还是WebService等远程对象技术， 不管是否真的在不同的服务器上部署， 至少在设计时要做这样的考虑， 更远的, 还必须考虑多个服务器通过负载均衡集群
因此，在考虑一个项目是否使用于三层/多层设计时， 首先要考虑是否真的需要。 其实大部分程序开Webaplication就够了， 没必要这么复杂。. 多层结构， 用于解决真正复杂的项目需求.”
有时三层之间不需要那么严厉，必须依据实际的业务逻辑来推断。这就是为什么软件开发没有固定的过程。