现在的位置: 首页 > 综合 > 正文

如何分层架构(杂记)

2011年10月23日 ⁄ 综合 ⁄ 共 8644字 ⁄ 字号 评论关闭
怎样分层:http://blog.csdn.net/llx529/archive/2005/08/15/455328.aspx

初学者,关于.net架构设计的问题?如何建立三层架构?from CSDN
最上层,数据访问data   access   layer,调用存储过程,运行sql语句.  
  中间曾,业务逻辑business   logic   layer,这一层封装业务逻辑,这一层调用数据访问层的方法.  
  用户界面User   interface.不用说了,这就是你的windows   form或者aspx页面.

简单点说,在你的项目里另外创建个两个文件夹,\dal和\bll  
  将数据访问类放到dal里,将所有的业务曾类创建到bll里.   
 

数据访问层,中间层都设计成类,编译生成dll  
  界面层,使用   DataLayer   obj   =   new   DataLayer();  
  obj.Method();  
  使用obj对象调用那中间层的方法。  
  中间层在调用数据层的方法。
接上面的,在dal里尽量数据库里一张表建一个类,bll里看你思路了
创建一个解决方案,添加需要的每层就可以了
就是表示层,业务逻辑层,数据访问层  
  参见petshop
csdn有好多文章是讲duwanmish的架构还有与petshop的比较你搜索下看看  
  层次是活的,但是我感觉就3层(数据层,业务逻辑层,表示层),其他的层都是为了程序的结构清晰或者代码的以维护移植等而进行扩充的。层其实就是个逻辑概念,通过做程序看别人的代码你还有你自己尝试用层来优化你的程序来体会层,光看是没有用的。

10 楼syeerzy(快乐永远*先天下之乐而乐*后天下之忧而忧*)回复于 2005-07-18 11:02:43 得分 30

新建一个空白解决方案。然后:  
   
  “添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“数据访问”(数据层,下简称D层)  
   
  “添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“业务规则”(业务层,下简称C层)  
   
  “添加”-“新建项目”-“其他项目”-“企业级模版项目”-“C#生成块”-“Web用户界面”(界面层,下简称U层)  
   
  右键点“解决方案”-“项目依赖项”,设置U依赖于C,C依赖于D。  
   
  对U添加引用C,对C添加引用D。  
   
   
  你想问的是这个????????   
   

Duwamiish7.0是五层  
  PetShop是三层

15 楼lyb_abiandbel(专注于OO分析与设计)回复于 2005-07-18 13:21:42 得分 10

这是我以前的学习petshop   3.0和duwamish   7.0的一点思考,  
   
  petshop是这样调用的:  
   
  (以product实体为例)实体product->BLL->DALFactory->IDAL->SQLServer   DAL  
   
   
  duwamish:  
   
  (以customer为例)customerdata数据->业务外观层GetCustomerByEmail()->数据访问层LoadCustomerByEmail()->Customer业务实体(这些业务实体全部是有DataSet承载)  
  ->调用存储过程->connetstring  
   
  提醒一下:调用接口函数实际上调用的是定义该接口函数的类的函数(记住这点才能清楚找到调用的过程)  
   
  以上是个人的理解,不知道能不能   帮你启发一下!

把每一层制作一个项目   然后引用他们的DLL文件到需要的项目里面   每层   也就是每个项目只作自己的事情   争取要作到出现错误或者升级维护只修改其中的一层   比如数据层   如果从SQL到ACCESS   你能保证只在数据库层修改。。。。。

听了lyb_abiandbel(渴望成为高手)   有所启发  
    TrojanSckiss所说的每一个层里都有.dll吗?我的目录里没有呀,是不是编译才能得到呢?
需要把你那层编译好以后在bin目录里面,在当前层添加引用,就可以使用以前的dll了。

如果你想学习,3层架构你就去看看java   的   MVC   框架比较好。  
   
  这个是java里面比较简单的一个了,你一定要记住页面流幺,呵呵。   .net的框架不够清晰。

不是.NET框架不清晰,而是太灵活了,所以出现了很多种框架,其实你自己结合实际选一种就可以了.  
  我一般也分三层,数据层(存储过程),业务逻辑层(一般用面向对象编写类),展现层(ASP.NET+WINDOW   FORM).  
  分析设计过程,先设计类,看看类里面要怎样访问数据库,再设计存储过程给类调用,最后用ASP.NET或WINDOW   FORM调用类中的方法实现系统   
 
++++++++++++++++++++
我对.NET不胜了解,不过,应该来说,.NET是一个平台,是一种面向INTERNET的分布式开发平台。而DNA还是建立在INTRANET范围以内的一种分布式架构。主要问题是以后的开发都向.NET转移,都是使用CLI库,不知道基于COM/DCOM/COM+的DNA架构位置在那里。还是请人进来继续讨论吧。
我的系分老师(在上海为软亚洲技术支持中心受训过)说,.NET是穿了一件漂亮外衣的DNA小姐。。。如果你扒光他的衣服,看到的就是DNA。

  不过,事实上两个构架的基础并不一样啊。.NET是基于CRL以及CRS等规范以及类库,而DNA架构是基于COM/DCOM/COM+,实在不知道有没有必要深入学习COM+知识了。彷徨中。。。
DNA是架构,软件模块的组织方式,系统模型.  
  而COM/COM+/.NET是具体的应用技术,解决手段.   
 
NET框架与COM                                     //ZT:中国   微软    
         
  背景和历史  
   
  可复用软件不是一个新概念。八年来,人们一直在使用各种形式的组件对象模型(COM)。事实证明,它是最为成功的可复用软件模型。COM引进了“组件”的概念——它是可复用的代码块,可以将多个独立函数的功能进行组合,从而扩充成诸如Microsoft   Word这样的应用程序。  
   
  大多数开发人员使用OLE时深刻体验了COM功能。OLE是基于COM形成的一组功能,使得用户能将一种文档嵌入到另一种文档中。这个功能本身似乎不太引人入胜,但它的作用却不同凡响:当用户将一个Excel文档粘贴到Word文档中后,单击嵌入的Excel文档时,OLE将会把Word的工具栏和菜单转换成Excel的工具栏和菜单。  
   
  从开发人员的角度看,COM通过引进几个明确定义的接口(诸如iUnknown)便可提供代码复用功能,开发期工具可通过这些接口来查询一个组件的功能,并能把这些功能添加到工具中。这就像Visual   Basic®开发系统工具箱中的控件能够被拖到某个窗体中一样。实际上,每个控件都代表上百行甚至上千行的代码,可以容易地封装在“黑匣子”中,开发人员只需直接调用其功能即可。  
   
  开发人员在使用COM时感到不便的一个问题是,他们必须编写附加代码来将业务逻辑程序转换成可复用的组件,同时还必须实现许多接口才能进行这种转换。最重要的是,COM要求开发人员必须手动处理复杂问题,比如:清空不再使用的组件曾占用的内存、计算组件的使用次数、建立或撤消线程和进程以及处理版本控制问题等。  
   
  有人可能认为,让开发人员亲自执行这类工作的主意非常好,但这也有几个弊端。首先,要开发人员一一执行上述所有工作非常困难,往往容易出错:导致应用程序错误、系统崩溃以及可怕的“DLL   Hell”。另外,严格地写出所有这种附加代码,会降低开发人员的工作效率,导致延期上市。  
   
  这对使用Visual   C++®开发系统的开发人员来说,尤其如此。而对使用Visual   Basic的开发人员来说,这种情况不是很严重。Visual   Basic抽象并简化了COM的许多概念,是全世界最具生产力、最流行的开发环境,但它的局限性在于:为了实现这种高生产力而不得不向开发人员屏蔽了COM的一些功能。  
   
  微软在2000年的专业开发人员大会(PDC)上引进的.NET框架,能自动在软件编写过程中进行“智能拼接”,使得开发人员可以集中精力编写业务逻辑,而不必编写COM基本结构。  
   
  什么是.NET框架?  
   
  .NET框架是一个多语言组件开发和执行环境,它由以下三个主要部分组成:  
   
   
  公共语言运行时。此名称不能准确反映它的全部功能。实际上,公共语言运行时在组件的开发及运行过程中,都扮演着非常重要的角色。在组件运行过程中,运行时负责管理内存分配、启动或删除线程和进程、实施安全性策略、同时满足当前组件对其它组件的需求。在开发阶段,运行时的作用有些变化:与现今的COM相比,运行时的自动化程度大为提高(比如可自动执行内存管理),因而开发人员的工作变得非常轻松。尤其是,映射功能将锐减开发人员将业务逻辑程序转化成可复用组件的代码编写量。对编程语言而言,运行时这个概念并不新奇:实际上每种编程语言都有自己的运行时。Visual   Basic开发系统具有最为明显的运行时(名为VBRUN),Visual   C++®跟Visual   FoxPro®、Jscript®、SmallTalk、Perl、Python和Java一样有一个运行时,即MSVCRT。.NET框架的关键作用在于,它提供了一个跨编程语言的统一编程环境,这也是它能独树一帜的根本原因。    
   
  统一的编程类。.NET框架为开发人员提供了一个统一、面向对象、层次化、可扩展的类库集(API)。现今,C++开发人员使用的是Microsoft基类库,Java开发人员使用的是Windows®基类库,而Visual   Basic用户使用的又是Visual   Basic   API集。只是简单地一用,.NET框架就统一了微软当前的各种不同类框架。这样,开发人员无需学习多种框架就能顺利编程。远不止于此的是,通过创建跨编程语言的公共API集,.NET框架可实现跨语言继承性、错误处理功能和调试功能。实际上,从JScript到C++的所有编程语言,都是相互等同的,开发人员可以自由选择理想的编程语言。    
   
  活动服务器页面(ASP+)。ASP+是使用.NET框架提供的编程类库构建而成的,它提供了Web应用程序模型,该模型由一组控件和一个基本结构组成。有了它,Web应用程序的构建变得非常容易。开发人员可以直接使用ASP+控件集,该控件集封装了公共的、用于超文本标识语言(HTML)用户界面的各种小器件(诸如文本框、下拉菜单等等)。实际上,这些控件运行在Web服务器上,它们将用户界面转换成HTML格式后再发送给浏览器。在服务器上,控件负责将面向对象的编程模型提供给Web开发人员,这种编程模型能提供面向对象编程技术的丰富功能。ASP+还提供一些基本结构服务(诸如会话状态管理和进程重启服务),这些服务大大减少了开发人员要编写的代码量,并使应用程序的可靠性得到大幅度提高。ASP+还允许开发人员将软件作为一项服务来提供。通过使用ASP+   Web服务功能,ASP+开发人员只需进行简单的业务逻辑编程,而由ASP+基本结构负责通过简单对象访问协议(SOAP)来提供服务。  
   
  与COM的关系  
   
  .NET框架的一个主要目的是使COM开发变得更加容易。COM开发过程中最难的一件事是处理COM基本结构。因此,为了简化COM开发,.NET框架实际上已自动处理了所有在开发人员看来是与“COM”紧密相关的任务,包括引用计算、接口描述以及注册。  
   
  必须认识到,这并不意味着.NET框架组件不是COM组件。事实上,使用Visual   Studio   6.0的COM开发人员可以调用.NET框架组件,并且在他们看来,后者更像是拥有iUnknown数据的COM组件。相反,使用Visual   Studio.NET的.NET框架开发人员则将COM组件视作.NET框架组件。  
   
  为了避免引起误解,这里需对这种关系加以特别说明:COM开发人员必须手动去做大多数.NET框架开发人员可以在运行时自动执行的事情。例如,必须手写COM组件的安全性模块,且无法自动管理模块占用的内存,而在安装COM组件时,注册条目必须放进Windows注册表中。对.NET框架而言,运行时实现了这些功能的自动化。例如,组件本身是自我描述型的,因而无需注册到Windows注册表中便能安装。  
   
  与COM+的关系  
   
  当把COM与Microsoft事务服务器(MTS)和分布式COM(DCOM)结合在一起时,就变成了COM+。COM+提供了一组面向中间层的服务。特别是COM+提供了进程管理功能和数据库与对象连接池处理功能。在将来的版本中,它还将提供一种称为分区的功能——专门为应用程序服务提供商设计的更强大的进程隔离功能。  
   
  COM+服务主要面向中间层应用程序开发,并主要为大型分布式应用程序提供可靠性和可扩展性。这些服务是对.NET框架所提供服务的补充;通过.NET框架类,可以直接访问这些服务。  

++++++++++
学习PEAA : Patterns Of Enterprise Application Architecture  

PEAA整理参考(持续)

Posted on 2007-10-27 14:40 sharplife 阅读(41) 评论(0)  编辑  收藏 所属分类: Agile dev

重读PEAA,把其提到的模式整理一下,方便参考

领域逻辑模式

事务脚本(Transaction script)
    使用过程来组织业务逻辑,每个过程处理来自表现层的单个请求

表模块(Table Module)
    处理某一数据库表或视图中所有行的业务逻辑的一个实例

领域模型(Domain Module)
    合并了行为和数据的领域的对象模型

服务层(Service Layer)
    通过一个服务层来定义应用程序边界,在服务层中建立一组可用的操作集合,并在每个操作内部协调应用程序的响应

数据源架构模式

表数据入口(Table Data Gateway)
    充当数据库表访问入口的对象,一个实例处理表中的所有的行

行数据入口(Row Data Gateway)
    充当数据库中单条记录入口的对象,每行一个实例

活动记录(Active Record)
    一个对象,它包括数据库表或视图的某一行,封装数据库访问,并在这些数据上增加了业务逻辑

数据库映射器(Data Mapper)
    在保持对象和数据库(以及映射器本身)彼此独立的情况下在二者之间移动数据的一个映射器

对象-关系行为模式

工作单元(Unit of Work)
    维护受业务事务影响的对象列表,并协调变化的写入和并发问题的解决

对象-关系结构模式

对象-关系元数据映射模式

Web表现模式

MVC模式
把用户界面交互分拆到三种不同角色中

页面控制器(Page Controller)
    在Web为特定页面或动作处理请求的对象

前端控制器(Front Controller)
    为Web站点处理所有请求的控制器,易于集中控制、易于抽象和装饰

模板视图(Template View)
    在html页面嵌入标记用于response信息

转换视图(Transform View)
    一项项处理领域逻辑,并将其转化成html的视图

两步视图(Two step View)
    先形成逻辑页面,在转换成html页面

应用控制器(Application Controller)
    应于处理屏幕导航和应用程序流的集中控制器,适于复杂的屏幕逻辑需求

分布模式

远程外观(Remote Facade)
    为细粒度对象提供粗粒度的外观用来改善网络上的效率,而服务层未必需要粗粒度封装

数据传输对象(Data Transfer Object)
    一个为了减少方法调用次数而在进程间传输数据的对象,有单一/多个(细分)的选择

离线并发模式

会话状态模式

客户会话状态(Client State)
    将会话状态保存在客户端

服务端会话状态(Server State)
    将会话状态以序列化的方式存放在服务端

数据库会话状态(DataBase State)
    将会话数据作为已提交的数据保存到数据库中

基本模式

入口(Gateway)
    Client用于封装外部系统或者资源访问的对象,而Facade通常由服务作者提供,用于简化服务API

映射器(Mapper)
    在两个独立的对象间通信的对象,通常于层间,如数据库映射器
    Mediator解藕个对象间关系,但各对象知晓Mediator本身的存在,映射器不为任一子系统所知晓

层超类(Layer Supertype)
    某一类型充当一层中所有类型的超类

分离接口
    在一个包中定义接口,在另外一个与这个包分离的包中实现接口

注册表(Registry)
    一个众所周知的对象,其他对象可以通过该对象公共的对象的服务,如 Facade Session

值对象(Value Object)
    一个如货币或日期这样的小而简单的对象,判等时不根据标识ID,如.NET的struct类型
    注:j2ee社区使用此名称表示数据传输对象

货币(Money)
    表示一个货币值

特殊情况(Special Case)
    对特殊情况提供特殊行为的子类,如Employee实现的NULLEmployee

插件(Plugin)
    在配置时而非编译时链接类,结合工厂、接口、单体的插件实现

    plugin.JPG

                                例图

interface IdGenerator... 
        public static final IdGenerator INSTANCE =
               (IdGenerator) PluginFactory.getPlugin(IdGenerator.class);
 

服务桩(Service Stub

       在测试时移除对具体服务的依赖,定义入口,以插件方式载入入口的实现,保持服务桩简单

       srvstub.JPG
                                图中Tax Service interface即为Gateway

记录集(Recordset

       表格数据在内存中的表现方式

整理持续中......

++++++

和一个公司技术总监的交流心得

交流结束之后,心里面想了很多,总结了以下几点:

1、对我个人来说,比较满意的项目:

建行招商管理系统(从学校出来工作之后,一个人完成第一个比较系统的、规范的小项目,客户比较满意 2004-04)

番禺交警综合信息网(开发asp这么久,第一次接触asp面向对象式的开发思路和DHTML,并在项目逐渐掌握这种技术,对个人asp技术来说是一个量到质的转变,对asp有了新的认识 。2004-08——2005-03)

中国贸易广州展览公司门户网站(这个项目是拖得比较久的一个项目了,项目开发过程中,比较全面的熟悉了ASP.NET(C#)的开发模式,在实践中更多的体会dowamish式架构的高效率,并能够在ASP.NET熟练使用C#开发和ADO.NET进行数据操作,总结了可以让自己使用的开发模式。2004-10——2005-03)

广州白云环卫局项目(这个项目是我们主管离开公司发展之后我们技术组的第一个项目,一个人完成了从需求整理、分析、文档编写、框架设计、编码、测试和售后支持,在对项目开发所需时间、开发过程中的不可预见因素有了新的认识,使自己对项目在宏观方面有了更好的把握。同时这个项目根据公司顾问反馈说客户很满意,在对方验收过程中基本上没有什么修改提出,这更增强了自己在担当更大任务方面的信心。2005-04)

2、文档的编写

文档的编写在一个项目管理方面还是很重要的,没有一个系统的需求分析文档和概要设计文档,几乎就不能够很好的管理好手下的项目组成员。也不能够很好的和上级领导沟通(只在项目进程上沟通是远远不够的)。同时对于一个项目经理来说,方案策划能力、需求分析能力、概要设计文档编写能力都是不可缺少。同时需要更好的理解其中各个方面的关系和侧重点。

方案策划是给客户看的,客户是否信赖我们,是否放心把一个项目交给我们来开发不仅要在跟客户交流中处理好彼此的关系,更需要有一个好的策划方案,让客户看了方案就可以明确的知道,我们的产品能够胜任客户在项目中的需要,在产品使用过程中,能够提高客户在相关方面的效率,让客户更好的在各个方面进行有效的沟通。

需求分析文档是处于概要设计和方案策划之间的文档。由项目经理来编写,其中涉及到项目在各个过程中的流程转向、各个流程之间的关系、注意事项、开发目的以及最终需要达到一种什么样的效果。

概要设计就主要是给开发人员来看的,这个非常重要,其中涉及程序的具体实现,也许这个超出了项目经理的工作范畴,但是在不完善的公司人员组成中,项目经理也应该能够做到这个原本是由系统分析员来编写的文档。

作为一个优秀的项目经理来说,我觉得以上几点应该是可以做到的。

+++++

抱歉!评论已关闭.