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

 三层架构

  • 常见架构
  1.  三层(经典)
  2. MVC
  3. MVVM
  4. MVP
  • 开发中常见的23种设计模式:

创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

  • 设计模式的六大原则

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

时间: 2024-07-30 04:26:49

浅谈.NET,C#三层架构(自己总结)的相关文章

浅谈MVC与三层架构

首先给大家引入下MVC的概念: MVC(Model View Controller)模型.视图以及控制器,它是一种较为广泛应用的结构设计模式. 模型:就是在MVC设计模式中需要被显示的数据.在通常情况下,该模型需要从数据库中读取数据.保存模型的状态等,提供数据的访问方法以及数据的维护. 视图:就是用来显示模型中数据的用户界面,一般来书,视图就是HTML页面. 控制器:就是用来处理对用户的输入或者交互命令,以便改变模型的状态,选择适当的视图来显示对应的模型数据. 工作机制如右图所示: (1)用户向

浅谈HTML5单页面架构(二)——backbone + requirejs + zepto + underscore

本文转载自:http://www.cnblogs.com/kenkofox/p/4648472.html 上一篇<浅谈HTML5单页面架构(一)——requirejs + angular + angular-route>探讨了angular+requirejs的一个简单架构,这一篇继续来看看backbone如何跟requirejs结合. 相同地,项目架构好与坏不是说用了多少牛逼的框架,而是怎么合理利用框架,让项目开发更流畅,代码更容易管理.那么带着这个目的,我们来继续探讨backbone. 首

AngularJS进阶(二十五)requirejs + angular + angular-route 浅谈HTML5单页面架构

requirejs + angular + angular-route 浅谈HTML5单页面架构 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs+angular+angular-route(+zepto) 最后这个zepto可有可无

浅谈图片服务器的架构演进

浅谈图片服务器的架构演进 现在几乎任何一个网站.Web App以及移动APP等应用都需要有图片展示的功能,对于图片功能从下至上都是很重要的.必须要具有前瞻性的规划好图片服务器,图片的上传和下载速度至关重要,当然这并不是说一上来就搞很NB的架构,至少具备一定扩展性和稳定性.虽然各种架构设计都有,在这里我只是谈谈我的一些个人想法. 对于图片服务器来说IO无疑是消耗资源最为严重的,对于web应用来说需要将图片服务器做一定的分离,否则很可能因为图片服务器的IO负载导致应用 崩溃.因此尤其对于大型网站和应

浅谈大型web系统架构

动态应用,是相对于网站静态内容而言,是指以c/c++.php.Java.perl..net等服务器端语言开发的网络应用软件,比如论坛.网络相册.交友.BLOG等常见应用.动态应用系统通常与数据库系统.缓存系统.分布式存储系统等密不可分. 大型动态应用系统平台主要是针对于大流量.高并发网站建立的底层系统架构.大型网站的运行需要一个可靠.安全.可扩展.易维护的应用系统平台做为支撑,以保证网站应用的平稳运行. 大型动态应用系统又可分为几个子系统: 1)Web前端系统 2)负载均衡系统 3)数据库集群系

浅谈HTML5单页面架构(一)——requirejs + angular + angular-route

本文转载自:http://www.cnblogs.com/kenkofox/p/4643760.html 心血来潮,打算结合实际开发的经验,浅谈一下HTML5单页面App或网页的架构. 众所周知,现在移动Webapp越来越多,例如天猫.京东.国美这些都是很好的例子.而在Webapp中,又要数单页面架构体验最好,更像原生app.简单来说,单页面App不需要频繁切换网页,可以局部刷新,整个加载流畅度会好很多. 废话就不多说了,直接到正题吧,浅谈一下我自己理解的几种单页面架构: 1.requirejs

浅谈工业级物联网项目架构设计及实施

[说明]这是发表在<程序员>电子刊10月B架构专题文章 网页链接:http://www.csdn.net/article/2015-10-31/2826093 摘要:互联网+和物联网由于发展的侧重点不同,在做架构设计上肯定有所不同.而以中小项目为主的物联网项目,其实更看重的,一是系统稳定可靠,能保证系统长期稳定的运行.本文主要介绍工业级物联网项目的架构设计及实施. 前言 早在1999年就已经有了“物联网”这个概念,但是直到十年之后的2009年,IBM提出“智慧地球”的概念,才推动很多国家把物联

浅谈数据仓库的基本架构(转)

数据仓库的目的是构建面向分析的集成化数据环境,为企业提供决策支持(Decision Support).其实数据仓库本身并不“生产”任何数据,同时自身也不需要“消费”任何的数据,数据来源于外部,并且开放给外部应用,这也是为什么叫“仓库”,而不叫“工厂”的原因.因此数据仓库的基本架构主要包含的是数据流入流出的过程,可以分为三层——源数据.数据仓库.数据应用: 从图中可以看出数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自上而下流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管

浅谈层次化的AI架构

原文地址:http://www.aisharing.com/archives/86/comment-page-1 记得在以前的一篇文章中谈到了一种类似于双缓冲的AI结构,最近在整理一些东西的时候,发现这样的AI结构具有一定的通用性,而且层与层之间耦合度相对较低,作为一种层次化的AI架构,非常值得一谈. 在我的脑海中,AI一般分为两个部分,一个是决策(Decision)部分,一个是行为(Behavior)部分,决策部分负责做什么,行为部分负责怎么做.在一些国外的公司里,AI程序员也大致分为这两种(