浅谈.NET,C#三层架构(自己总结)_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 浅谈.NET,C#三层架构(自己总结)

浅谈.NET,C#三层架构(自己总结)

 2017/8/25 10:08:55  大城小梦  程序员俱乐部  我要评论(0)
  • 摘要:三层架构常见架构:三层(经典)MVCMVVMMVP开发中常见的23种设计模式:创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。设计模式的六大原则1、开闭原则2、里氏代换原则3、依赖倒转原则4、接口隔离原则5、迪米特法则
  • 标签:总结 .net C# net 自己 浅谈 架构

 三层架构

  • 常见架构
  1.  三层(经典)
  2. MVC
  3. MVVM
  4. MVP
  创建型模式,共五种:工厂方法模式、抽象工厂模式单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
  • 设计模式的六大原则
1、开闭原则 2、里氏代换原则 3、依赖倒转原则 4、接口隔离原则 5、迪米特法则(最少知道原则) 6、合成复用原则  
  • 程序与程序交互方式
1.引用命名空间 2.文件(IO,servile),文件流,序列化 3.DB数据库 4.web请求(Ajax)(Socket)(HTTPRequest 提交方式:get,post)  
  链接1(百度百科): https://baike.baidu.com/item/%E4%B8%89%E5%B1%82%E6%9E%B6%E6%9E%84/11031448?fr=aladdin 连接2(必看):http://blog.csdn.net/hanxuemin12345/article/details/8544957/ 高内聚低耦合: https://baike.baidu.com/item/%E9%AB%98%E5%86%85%E8%81%9A%E4%BD%8E%E8%80%A6%E5%90%88  
  1.概念: 三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为:
  • 界面层UI(User Interface layer)
  • 业务逻辑层BLL(Business Logic Layer)
  • 数据访问层DAL(Data access layer)
区分层次的目的即为了“高内聚低耦合” 任何一层发生变化都不会影响到另外一层!!!   1:数据访问层:主要是对非原始数据的操作层,是对数据库的操作,具体为业务逻辑层或表示层提供数据服务 2:业务逻辑层:主要是针对具体的问题的操作,对数据业务逻辑处理 3:界面层:展示层,交互界面,主要表示WEB方式,也可以表示成winform方式。     2.高内聚低耦合: 概念   耦合性:也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密,其耦合性就越强,模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息   内聚性:又称块内联系。指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素(语名之间、程序段之间)联系的越紧密,则它的内聚性就越高。   耦合:一个软件结构内不同模块之间互连程度的度量。   低耦合,粗浅的理解是:一个完整的系统,模块与模块之间,尽可能的使其独立存在。   高内聚是指一个软件模块是由相关性很强的代码组成,只负责一项任务,也就是常说的单一责任原则。   3.优缺点: 优点 1、开发人员可以只关注整个结构中的其中某一层; 2、可以很容易的用新的实现来替换原有层次的实现; 3、可以降低层与层之间的依赖; 4、有利于标准化; 5、利于各层逻辑的复用。 6、结构更加的明确 7、降低维护成本和维护时间 缺点 1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。 2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。 3、增加了开发成本。   4.实体层(Entity):(看连接2)   Entity(实体层):它不属于三层中的任何一层,但是它是必不可少的一层 实体类库(Model),主要存放数据库中的表字段。   4,每一层(UI—>BLL—>DAL)之间的数据传递(单向)是靠变量或实体作为参数来传递的,这样就构造了三层之间的联系,完成了功能的实现。 但是对于大量的数据来说,用变量做参数有些复杂,因为参数量太多,容易搞混。比如:我要把员工信息传递到下层,信息包括:员工号、姓名、年龄、性别、工资....用变量做参数的话,那么我们的方法中的参数就会很多,极有可能在使用时,将参数匹配搞混。这时候,如果用实体做参数,就会很方便,不用考虑参数匹配的问题,用到实体中哪个属性拿来直接用就可以,很方便。这样做也提高了效率。   (注:这里为什么说可以暂时理解为每个数据表对应一个实体??答:大家都知道,我们做系统的目的,是为用户提供服务,用户可不关心你的系统后台是怎么工作的,用户只关心软件是不是好用,界面是不是符合自己心意。用户在界面上轻松的增、删、改、查,那么数据库中也要有相应的增、删、改、查,而增删改查具体操作对象就是数据库中的数据,说白了就是表中的字段。所以,将每个数据表作为一个实体类,实体类封装的属性对应到表中的字段,这样的话,实体在贯穿于三层之间时,就可以实现增删改查数据了) 综上所述:三层及实体层之间的依赖关系:   5.代码: 三层架构简单代码: http://blog.csdn.net/zhgl7688/article/details/43669463#comments  
发表评论
用户名: 匿名