简述分层架构的设计中要遵循哪些原则

1、最关键的，UI层只能作为一个外壳，不能包含任何业务逻辑(BizLogic)的处理过程；

2、设计时应该从BLL出发，而不是UI出发. BLL层在API上应该实现所有BizLogic，以面向对象的方式；

3、不管数据层是一个简单的SqlHelper也好，还是带有Mapping过的Classes也好，应该在一定的抽象程度上做到系统无关；

4、不管使用COM+(Enterprise Service），还是Remoting，还是WebService之类的远程对象技术，不管部署的时候是不是真的分别部署到不同的服务器上，最起码在设计的时候要做这样的考虑，更远的，还得考虑多台服务器通过负载均衡作集群。

扩展资料

各层的作用：

1、数据访问层：主要是对非原始数据的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。

2、业务逻辑层：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。

3、界面层：主要表示WEB方式，也可以表示成WINFORM方式，WEB方式也可以表现成：aspx，如果逻辑层相当强大和完善，无论表现层如何定义和更改，逻辑层都能完善地提供服务。

参考资料来源：百度百科——三层架构

设计原则：
1：系统分为多层，每层完成独立的功能，层内部继续细分子模块，每层能够独立演进、部署。分层原则可以基于业务抽象、硬件、变化性等来划分，比如sqlite就是基于业务抽象来进行分层的。实际的框架设计可能同时结合多种维度比如常见的表示层、逻辑层、数据层就结合了业务抽象和变化两个维度。

2：各层的功能基于同层和底层的功能之上，如图所示L1的所有功能基于本层、L2、L3（实际设计中不建议基于跨层功能），也就是说上层只能调用本层和下层的接口。这样的设计避免互相调用导致的结构复杂。

3：各层提供相应的接口与实现分离，对该层的访问只能通过接口进行。通过接口进行访问有效的分离了关注点。外层关注接口，层内部关注接口的实现，实现的修改不会对其它层产生影响。实际应用中可以使用适配器模式来有效的分离接口和实现。假设业务数据可能通过不同的协议栈承载实际数据的传输，不同的协议有不同的实现，我们可以如下设计接口：
4：底层不能依赖高层的功能，这样设计避免了结构的复杂，你不能指望操作系统来调用你的接口吧。但是一些系统的事件确实需要上层应用做出相应的处理，该如何处理呢？这就需要用到观察者模式了，在C语言中一般通过回调机制来实现，这时下层提供接口，上层把实现注册进去。这样底层就可以在不调用上层的接口下控制上层的行为了。
5：数据流是双向交换的，比如在协议栈中数据可以在相邻的层次之间交换的，下层到上次的数据流可以有多种方式比如消息机制、回调机制等。消息机制有利于分布式部署并且是一种松耦合的形式，只要接收双方定义了消息格式即可，不再需要依赖具体的接口。

分层架构通过对关注点的分离有利于分化系统的复杂性，提高系统的可扩展和可维护性，但在分层架构中为了获取底层的功能可能需要进行多个层次的传递，不可避免的导致性能的下降。为了保持架构的稳定在开发中增加功能往往需要在各层都要添加相应的代码。