.Net下企业应用系统架构构建心得

这篇具有很好参考价值的文章主要介绍了.Net下企业应用系统架构构建心得。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

在开始架构设计之前,需要了解一下架构是什么,按照IEEE标准的定义是: Architecture 是一个系统的基本组织,它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。 (The embodied fundamental organization of a system in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE Std 1471-2000])


  一句话,架构就是软件产品的骨架,这个骨架把组件、环境纳入其中,使之能有效得发挥它们的技能。
  从架构、技术和需求的关系来看。一个软件产品包含了需求和技术,而架构同样是要包括需求和技术的,只是它没有全包全括这个需求和技术,应该是一些整体性的需求,尤其是一些非功能性的需求。如果在构建架构的时候,架构设计人员根本不了解企业使用的目标软件的整体需求,企业使用目标系统的整体环境,那指望架构适用显然有点强求。


  架构的重要性是不言自明的:
  l)从需求、技术和架构的关系看,架构是软件产品的骨架
  2)从软件过程上看,架构处在需求即将完成,实现开始之前,是一个承上启下的关键点
  3)从技术上来看,架构是整体设计,包含了软件需要用到的各项技术
  4)架构决定开发过程,方法和工具,这一点都不夸张,架构决定了软件的规模,技术。很自然就觉得了资源的需求以及如何配置这些资源来进行开发
  5)架构影响软件产品的成本,包括开发成本,测试,实施和维护成本 架构实际上是软件的一部分,同样都需要遵循软件设计中要考虑的设计原则。但是,架构由于是前期设计,整体设计,又具有其需要强调的地方:
  6)明确目标,切合需求(实用决定一切)
  7)可扩展性
  8)易用性和易维护性平衡艺术,易用性就要求系统不能过于负杂,而易维护性就要求可扩展性和灵活性,就要求系统不能太过简单,这就要权衡这两个性能方面的考虑。
  9)安全性, 架构的安全并不是说把架构的代码放到一个地方加密,是在架构设计中考虑软件的安全性能,这个在先期考虑是相对重要的。


  l0)稳健性, 架构设计时需要纳入考虑的要素有:
  l1)Application Infrastructure, 应用的基础架构,也可以说是架构是建立在什么平台上的,比如windows 2003+.Net framework 1.1,当然并不是就这么简单,下面会有具体的讲解。
  l2)Management, 架构设计中要考虑用户对软件的管理方面的考虑,比如用户对性能监控的要求,用户要对软件执行各个环节的执行效率统计等等。
  l3)Security, 安全性是在什么地方都要考虑的,不光是软件开发。
  l4)Storage, 存储,面对一个企业级的应用而言,对存储的要求是要特别注意的。
  l5)Network,网络拓扑结构,以及企业对网络的要求层级,数据传输要求等等。
  在了解了软件架构的这些本本上的东西,那么我们来搭个应用看看。以我碰到的项目为例,当然一些技术是可通用的,但这个是一个个案,不代表适用您的项目,只求交流。

  先交待一下,假设:
  1. 系统是建立在微软的架构基础上的,Microsoft System Architecture (MSA)
  2. 它是一个B/S的N-Tier架构
  3. 同时它是一个企业级应用系统,信息平台


  在考虑使用N-Tier的过程中,由于系统中没有涉及到要使用跨平台的应用,在可预见的将来也不会有,所以就把Web Service拿掉了。Web Service从3年前就开始用,但是几个问题还是没有解决:
  1.Web Service从接口继承,如果两个或者两个以上的Web service同时从相同的接口继承,由于Web Service的自描述性,每个Web Service都重新生成接类,就成了两个不同的类。
  2.Web Service本身不能被继承,同样由自描述性搞的。
  3.Web Service要真正做到跨平台那就需要做到跨语言,从Java到C#的转化时数据类型转化是相当麻烦的,基本类型之间就有很大问题,如byte,sbyte(C#)中,当Java中根本就没有sbyte。早在一年半前曾用相异平台做了一个应用系统,为了处理这个数据类型转化,我曾想去掉Web Service。
  4.Web Service方法不能重载,这个很恐怖。
  5.Web Service的安全问题。
  尽管Web Service有其种种好处,连现在的网格都开始醉心于它,更不用说SOA了,本身就是以Web Service为核心展开的。但是,Web Service到底能走向哪里?
  在开始架构设计之前,需要了解一下架构是什么,按照IEEE标准的定义是: Architecture 是一个系统的基本组织,它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。 (The embodied fundamental organization of a system in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE Std 1471-2000])


  一句话,架构就是软件产品的骨架,这个骨架把组件、环境纳入其中,使之能有效得发挥它们的技能。
  从架构、技术和需求的关系来看。一个软件产品包含了需求和技术,而架构同样是要包括需求和技术的,只是它没有全包全括这个需求和技术,应该是一些整体性的需求,尤其是一些非功能性的需求。如果在构建架构的时候,架构设计人员根本不了解企业使用的目标软件的整体需求,企业使用目标系统的整体环境,那指望架构适用显然有点强求。
  具体的了解一下这个层的关系,以及构建架构时上文提到的需要涉及到的问题。


  1. Presentation Tier
  表示层分层两层,UI Components可以直接看作是HTML,UI Process 这里不是MVC,而是code-behind类。 在表示层,就我所碰到需要处理的问题有:
  l)MVC (Model-Views-Controller)
  Asp.net下是否需要使用MVC一直是一个有争议的问题。 Asp.net的特点是事件驱动与Code-behind,Code-behind本身就可以理解是MVC中的Controller,但是没有体现MVC的好处来,微软缺乏双向赋值的考虑。UIP (User Interface Process Application Block )是微软社区里的一个开源项目。严格说来它只是一个管页面流转,不是一个MVC的框架。Maverick.net是一个比较轻量级的框架,简单实现了MVC,但是也有其缺陷,而且比较老了。 还有Castle的框架,Spring还没有完整推出。


  2)国际化
  如果是一个多语言的企业应用,那就需要国际化支持,.Net提供了很好的国际化支持。
  3)页面元素格式统一转化与验证
  比如日期形式从“yyyy-mm-dd”需要转化成“yyyy/mm/dd”,如果没有一个统一配置的地方,那页面就要伤筋动骨了。
  4)安全,在后面的安全节有介绍,这里先按下不提

    2. Web Service
  这里不再说了,已经去掉了。
  3. Business Tier
  Business 层是应用系统的核心,包括体现用户的商业运算逻辑的Business Logic;还有保障Business Logic运算安全和完整性的事务,日志,安全验证,性能管理等辅助逻辑。在设计Business Tier的时候要考虑的问题有:
  l)可扩展性
  i.将接口进行到底
  在Business实现层之上,建议抽出一个接口层,遵循一般原则提倡接口编程, Business Components都从一个或者一个以上接口继承,在调用代码中调用类工厂产生实例,在代用代码中建议不要使用此类的new操作符。
  ii.设计模式的应用
  适当应用模式,可以增加程序的灵活性,可扩展性。(在设计中经常用到Factory,Adapter,Singleton,Decorate,Command,Template等模式,建议可以重点了解一下这些模式。有时间可以详读GOF的设计模式)Example:从Business结构,划分为CRUD(增查改删,称为“四架马车”)和其它具体业务实现的Components,这里用Decorate模式,简单实现一个继承的过程,如果你要继承两个基类,可以考虑使用此模式,当然,即使不继承基类,用Interface+Adapter同样可以实现多继承。


  2)区分业务逻辑
  所谓区分业务逻辑实际上在上面的描述中已有提及,大致上可以分为两类,一类是商业业务逻辑,一类则是软件功能性逻辑,起辅助保障上述逻辑用,如事务,日志,安全验证等。第二类的使用频率高,实现又是非常类同的,如果提取出来,那复用价值是很高的。 这种区分早有定义,把抽出来的部分称之为CrossCut或者叫Aspect。这个就是AOP在事务,日志,安全验证方面的应用。先来看一下CrossCut(Aspect)的结构表示图:

3)MS组件、服务的是应用
  这里的服务和组件主要是讲是在Application infrastructure中的元素,如COM+,MSMQ,IIS,AD等等。这里常用到的两种COM+和MSMQ。
  i.COM+
  如果应用系统需要使用分布式事务,或者的确希望把组件编程一个服务,那么就可以使用COM+,当然这也造成部署的不方便。
  ii.MSMQ
  消息队列,主要使用于异步处理。比如,在业务处理过程中要发一封邮件,如果采用消息队列来做,不管当前的邮件服务忙,还是根本就不能工作,用户可以转回来处理其它业务而不必等待。


  4. DataAccess Tier
  数据访问层,是用来隔离系统访问不同的数据媒体或者系统外服务(比如,其它系统的Web Service等)用的。
  l)将接口进行到底
  2)or-Mapping,OR Mapping所带来的好处这里就不多说了。我们先来谈一下下面的几个概念。

   i.Domain Model & Table Module
  根据Martin Flower的定义Domain Model:An object model of the domain that incorporates both behavior and data.
  - Rich Domain Model :是上面的这种定义
  - Anemic Domain Model :这种方式方法和Data是分别在不同的类里实现的,OR-Mapping就是建立在这种方式上的。
  ii.NHibernate
  NHibernate是OR-Mapping的一种实现,是一个比较齐整的框架,是从Java的Hibernate转过来的。当然.Net下还有其它的OR-Mapping实现,如Gentle.net
  iii.SqlMapper & IBatis.Net
  SqlMapper为Domain Model和Table Module两种方式一个折中方案,它可以以面向对象的方式直接处理自定义数据实体对象,同时可以根据与数据源与业务实体的映射关系执行手写的Sql语句,这样完全使得我们可以针对具体数据源做优化,对于复杂操作同样可以胜任。IBatis.Net 是SqlMapper的实现。
  3)or-Mapping与复杂查询的问题
  OR-Mapping带来的好处是在CU,D方面还可以,毕竟大批量的删除一般不会经常出现,但是R方面就是一个实实在在的问题,面对复杂查询的执行效率也是一个问题。蹩脚的解决方案是两条线,R这方面采用Table Module这种方式来,而CUD才用对象。


  5. Commom Tier
  是系统性能、检测、跟踪用的,有些可以采用AOP来解决,如计数等。


  三.企业级应用
  企业级应用一般的特点是数据量大,交互操作要求高,在线用户量比较大,用户地理分布较广。这就要求我们在设计架构是要考虑其安全性,数据存储要求,集群,与其它应用交互。
  l)安全性
  安全性是一个多角度多方位的立体式问题,应用体统的安全性,是与其它安全性一起才构建起来。 一般安全分成几个层级:
  1.网络安全性
  -网络服务的安全,如http,ftp,mail


  2.操作系统安全性
  -访问控制表(ACL)安全控制,主要通过组、用户权限控制完成
  -网络访问安全控制,在域模式下
  3.数据安全性
  - 数据库系统安全
  -数据访问权限安全
  - 数据加密
  -数据备份


  4.应用系统安全性
  -Asp.net的安全性
  -安全通信
  对于上面列举的一些安全层次,有些是在系统的使用过程中要注意的问题,并非在架构设计时能做到的,但是,可以做为输入项来构建一套安全的系统。下面主要来讲一下如何用Asp.net来构建安全的系统。
  1.Asp.net安全性
  -ASP.NET 身份验证,包括 Windows、表单、Passport 和无身份验证
  -ASP.NET 授权,包括URL 授权、文件授权 、主体权限需求 和.NET 角色
  -标识和主体,主要是通过编程方式来进行(标识和主体对象必须实现 IIdentity 和 IPrincipal 接口。这些接口在 System.Security.Principal 名称空间内定义 )


  2.在采用windows验证时,Asp.net可以在IIS上配置一些安全选项。


  3.安全通信
  -Internet协议安全(IPsec)
  IPSec 提供传输级安全通信解决方案,可以用于保护两台计算机之间传送的数据安全 。VPN也是在这个协议基础上构建的。
  -安全套接字(SSL)
  这通常用于保护浏览器和 Web 服务器之间的通道安全。 结合IIS和证书,就可以配置https协议使用。
  -远程调用(RPC)加密
  分布式 COM (DCOM) 使用的 RPC 协议提供了一个身份验证级别(数据包保密性),它对客户端和服务器之间传送的每个数据包都进行加密。


  2)存储
  企业级应用级的存储特点是I/O访问要求高,数据容错性要求高。所以,就有可能使用比较高端的存储设备以满足存储要求,硬件不是软件系统架构的内容,但是Raid等使用却是软件架构必需考虑的。


  3)集群
  同存储要求一样,对于一个大型的应用来说,大访问量,分布式数据应用,就可能需要使用集群。
  对于分布式数据库的需要使用数据库集群,可采用数据库系统本身得到解决。
  对于分布式部署需要应用服务器集群,这在代码实现上就要先期考虑到Session在分布式部署环境下的同步问题。
  4)与其它应用交互
  在设计架构时,还要考虑与其它系统的交互。
  1.使用其它系统的接口
  2.与原有系统的整合
  3.开放接口,供其它系统使用文章来源地址https://www.toymoban.com/news/detail-421236.html

到了这里,关于.Net下企业应用系统架构构建心得的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 浅谈企业能源监测管理系统的设计与应用

    安科瑞 华楠 摘要:  针对企业目前能源监测现状, 结合企业信息化建设情况和发展需要, 介绍了能源监测管理信息系统, 提出了企业能源监测管理系统建设建议。  : 管理系统; 能源监测; 企业信息化 0 引言 节能降耗是缓解中国资源约束的根本出路, 也是提高企业自主创新

    2024年02月11日
    浏览(51)
  • 分布式应用:ELK企业级日志分析系统

    目录 一、理论 1.ELK  2.ELK场景  3.完整日志系统基本特征 4.ELK 的工作原理          5.ELK集群准备 6.Elasticsearch部署(在Node1、Node2节点上操作) 7.Logstash 部署(在 Apache 节点上操作) 8.Kiabana 部署(在 Node1 节点上操作) 二、实验          1.Elasticsearch部署(在Node1、Node2节点上

    2024年02月14日
    浏览(41)
  • 【分布式应用】ELK企业级日志分析系统

    目录 一、ELK 简介 1.1 ELK各组件介绍 ElasticSearch: Kiabana: Logstash: 1.2 可以添加的其它组件: Filebeat: 缓存/消息队列(redis、kafka、RabbitMQ等): Fluentd: 1.3 ELK、ELFK、EFLKL 二、为什么要使用 ELK 三、完整日志系统基本特征 四、ELK 的工作原理 五、ELK集群部署 实验环境: 实验步

    2024年02月14日
    浏览(44)
  • 低代码应用开发 高效构建业务系统

    低代码是传统软件开发逐步优化和演变的产物,并非全新革命。传统的开发方法过于昂贵和僵化,无法为企业提供所需的高效和敏捷的开发流程,且交付周期长定制能力弱,难以应对不断变化的市场和客户期望,为提高软件开发效率,对代码进行模块化组装的低代码产品进入

    2024年02月12日
    浏览(44)
  • 工程建材企业必看:应用集中采购协同系统,实现降本增效,提升企业效益!

    建材是土木工程和建筑工程中使用的材料,可分为结构材料、功能材料和某些专用材料。近年来,受益于科技的进步和建筑水平的提升,我国工程建材行业获得了蓬勃发展,成为拉动国民经济发展的重要产业。 当前,由于受到建筑材料价格波动的影响,工程建材行业面临挑战

    2024年01月16日
    浏览(41)
  • 新零售SaaS架构:订单履约系统的应用架构

    通过分析订单履约的全流程和各个业务活动,我们可以梳理出订单履约的核心业务链路,基于业务链路,我们抽象出订单履约系统的三大系统能力,分别为履约服务表达、履约调度、物流配送。   履约服务表达 :负责向客户明确和准确地传达履约服务,包括提供订单的预计

    2024年03月09日
    浏览(49)
  • 系统架构主题之五:软件系统建模方法及其应用

    前面我们梳理了需求分析的相关内容。完成需求分析后,会输出指导软件开发的需求规格说明书。有了该文档的支持,下一步就是系统设计阶段,用于将软件需求的内容转换为可指导软件开发的概要设计和详细设计文档。下面我们从理论和实践上看看如果做系统设计。 1 信息

    2024年02月07日
    浏览(42)
  • Docker和Kubernetes:构建现代应用容器编排系统

    作者:禅与计算机程序设计艺术 Docker是一个开源的应用容器引擎,可以轻松打包、部署及运行应用程序。Kubernetes(简称K8s)是一个开源的,用于管理云平台中多个主机上的容器化的应用的容器集群管理系统。通过对Docker和Kubernetes的结合,能够更高效地自动化地部署和管理容

    2024年02月07日
    浏览(44)
  • 新零售SaaS架构:客户管理系统的应用架构设计

    应用层定义了软件系统的应用功能,负责接收用户的请求,协调领域层能力来执行任务,并将结果返回给用户,功能模块包括: 客户管理:核心功能模块,负责收集和更新客户信息,包括个人资料、联系方式、消费习惯、会员卡、归属信息(比如销售或顾问)和备注。这个模

    2024年04月08日
    浏览(47)
  • 系统架构主题之七:基于架构的软件设计方法及应用

    1 基于架构的软件设计方法概念 :ABSD、自顶向下、递归迭代、与需求同步、设计元素、视角与视图、用例和质量场景、预期和非预期等。 总的来讲,ABSD方法分为如下六个大的阶段: 1)体系结构需求阶段 相比传统软件系统设计,架构设计在需求获取、分析之后展开不

    2024年02月11日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包