架构图用什么软件
独家VIP文件
VIP专属文档是百度文库认证用户/机构上传的专业文档。图书馆VIP用户或购买VIP专属文档下载特权包的其他会员用户，可以免费下载VIP专属文档，并拥有VIP专属文档下载特权。带有以下“贵宾专属文件”标志的文件就是这样的文件。了解文档类型
贵宾免费文件
VIP免费文档是一种特定的共享文档，会员用户可以免费获取，非会员用户可以通过开通VIP获取。带有以下“VIP*文档”标志的文档就是这样的文档。了解文档类型
贵宾享受文件八折优惠
VIP专属八折单据是一种特殊的付费单据，会员用户可以按设定价格的八折获得，非会员用户需要按原价获得。带有以下“VIP专属八折”标志的文件就是这样的文件。了解文档类型
支付凭证
付费文档是百度文库认证用户/机构上传的专业文档，需要文库用户支付人民币获取，具体价格可由上层子孙*设定。带有以下“付费文档”标志的文档就是这样的文档。了解文档类型
共享文档
共享文档是百度文库用户免费上传的文档，可以与其他用户免费共享，具体共享方式由上层后代*设置。带有以下“共享文档”标志的文档就是这样的文档。了解文档类型
PS:看三层架构的时候，发现了一个我觉得不错的素材。下面有图。我打算详细解释一下这张图，总结一下三层知识
一.系统各级的责任
1.1。UI(UserInterface)层负责数据的展现和采集，数据采集的结果通常会提交给bl层作为Entityobject进行处理。服务接口层用于将业务或数据资源发布为服务(如网络服务)。
2.2的责任。BL(BusinessLogic)层是根据预定的业务逻辑处理UI层提交的请求。
(1)业务功能子层负责基本业务功能的实现。
(2)BusinessFlow子层负责将BusinessFunction子层提供的多个基本业务功能组织成一个完整的业务流程(交易只能在BusinessFlow子层打开。)
3.资源访问层的职责是提供全面的资源访问功能支持，屏蔽上层的资源来源。
(1)BEM(BusinessEntityManager)子层采用数据访问子层和服务访问子层，提供业务所需的基本数据/资源访问能力。
(2)DataAccess子层负责从数据库中访问资源，屏蔽所有的SQL语句和数据库类型区别于BEM子层。
数据库适配器子层负责屏蔽数据库类型的差异。
ORM子层负责提供对象关系映射的功能。
关系子层提供了ORM无法完成的基于关系的数据访问功能。
(3)ServiceAccess子层用于以SOA的方式从外部系统获取资源。
注意：服务条目用于简化对服务的访问，相当于服务的代理。客户可以使用服务条目直接访问系统发布的服务。ServiceEntrance为特定平台(如Java、)提供强类型接口。Net)，内部可能隐藏复杂的参数类型转换。
(4)配置访问子层用于从配置文件中获取配置对象或将配置对象保存在反向配置文件中。
4.实体侧层跨越用户界面/边界元/资源管理器层，并在这些层之间传输数据。实体侧图层包含三种类型的实体，如下图所示：
第二，方面
方面贯穿于系统的所有层次，这是系统的横切关注点。AOP技术通常用于建模和实现横切关注点。
1.安全性方面：用于支持整个系统的安全性。
2.错误处理方面：整个系统采用一致的错误/异常处理方法。
3.日志方面：用于系统异常、日志记录、业务操作记录等。
三.规则
1.系统的所有级别和级别内的子级别不得跨级别调用。
2.实体对象在层之间传输数据。
3.需要绑定到列表的数据
4.每个数据库表对应一个数据库实体类，每个实体类对应一个类。
5.一些跨数据库或跨表的操作(如复杂的联邦查询)需要由相应的BEMClass支持。
6.对于一个相对简单的系统，可以考虑将业务功能子层和业务流子层合并成一个。
7.7中不允许有任何SQL语句。UI层和BL层。
四.错误和例外
异常可分为系统异常(如突然断网)和业务异常(如用户输入值超出最大范围)。业务异常必须转化为业务执行的结果。
1.1。数据访问层不得向上层隐藏任何异常(该层抛出的几乎所有异常都是系统异常)。
2.清楚地区分业务执行结果和系统异常。比如验证一个用户的有效性，如果对应的用户ID不存在，就不应该抛出异常，而应该返回一个表示验证结果的枚举值(或者通过out参数)，这是业务执行的结果。但是，如果您从数据库中读取中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。
3．在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
4．UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。
五、项目组织目结构
以BAS系统为例。
1．主目录结构：
2．命名空间命名：每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
3.包含众多子项目的庞大项目的物理组织：
核心子项目Core的位置：
Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。
六、发布服务与服务回调
以EAS系统为例。
1．同UI层的Page一样，服务也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败)的形式来表明服务调用出现了错误，如果方法有返回值，则返回值以out参数提供。
2.如果BAS系统提供了WebService（Remoting）服务，则BAS必须提供BAS.Entrance.dll。BAS.Entrance.dll封装了与BAS服务交换信息的通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。
3．如果BAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供BAS回调。
4．当WebService的参数或返回值需要是复杂类型――即架构图中的ServiceEntity，则ServiceEntity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。WebService定义的方法中的复杂类型应该使用Xml字符串代替（注意，Entrance和CallBack接口对应服务的方法的参数是强类型的），而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。
之前用一张图分析了Google给出的MVP架构，但是在Google给出的所有案例里面除了基本的MVP架构还有其它几种架构，今天就来分析其中的Clean架构。同样的，网上介绍Clean架构的文章很多，我也就不用文字过多叙述了，还是用一张类图来分析一下Clean架构的这个案例吧。好了，先直接上图！
上完图，再说一说我对Clean架构的一个理解吧。对比前一篇文章的MVP架构图可以看出，clean在一定程度上继承了mvp的设计思想，但是其抽象程度比mvp更高。初次看这个demo的时候，确实被震撼了一下——原来用Java可以这样写代码！！！跟之前用的一些项目框架和我自己平时写的一些代码对比一下，只能感叹clean的这种设计思想真不是一般的程序员可以想出来的。它对接口、抽象类和实现类之间的实现、继承、调用关系发挥到了一个比较高的层次，它并不是像我们平时写代码那样很直白地写下来，而是充分利用了面向对象的封装性、继承性和多态性，是对面向对象思想的一个高度理解。其实，要说clean复杂，它确实有些难理解，可是如果你真的理解了面向对象思想，那么又会觉得这样的设计完全在情理之中。
最近几个月都没有整理Blog，都忙着整理总结之前一段时间做的项目和学习的内容，然后想到把这些东西融合在一起，设计一个开发框架。
这个框架用到了一些.NET社区比较前沿的技术，比如ORM, IOC容器, AOP拦截等，在.NET 2.0的基础上构建了一个.NET Remoting的分布式开发框架。
项目开发最关注的就是开发效率，其次是项目的可管理可控性，最后是架构的可扩展性。我希望在我的框架设计中能够将这三者很好的整合在一起。
大致的思路是：
1、可扩展性：通过IOC容器的使用降低项目中各个模块之间的依赖性；用领域模式来设计业务核心层，降低业务层对数据层和界面层的耦合度；分布式选择Remoting为主，可以再包装为WebService或者直接发布为WebService。
2、将敏捷的项目管理思路引入到框架中，框架充分支持TDD测试驱动和运行日志驱动，为敏捷管理提供技术支持。
3、初步通过AOP技术减少和核心业务无关的系统级代码：如事务处理、异常处理、日志记录等；并在将来为架构提供可视化的代码配置生成工具，以最快的速度构建项目的主体结构，并尽可能大的增大灵活性。
目前框架的主体已经完成，也重新整理VSS上的项目结构，并重新命名为LightningFramework。正在做细节调整，接下来的时间会逐步完成相关文档和演示程序。下面是主架构图：