2016年10月23日 20:11:03 阅读数:10646 在Java中 VO. PO.DO.DTO. BO. QO.DAO.POJO的概念中介绍过Java中的各种模型概念.在这里简单再总结一下: 在日常的项目开发中,VO对应于页面上需要显示的数据(表单),DO对应于数据库中存储的数据(数据表),DTO对应于除二者之外需要进行传递的数据. 很多人可能对VO和DTO并不是那么熟悉,相反对DO却比较熟悉,那是因为在很多项目中由于种种原因我们只使用了DO,原因可能有以下几种: 1.项目太小,对于

Service层主要提供的几个作用:1.将业务逻辑层进行封装,对外提供业务服务调用.2.通过外观模式,屏蔽业务逻辑内部方法.3.降低业务逻辑层与UI层的依赖,业务逻辑接口或实现的变化不会影像UI层.4.降低UI层调用的请求次数及数据往返. DTO层主要提供的作用: 在上面的结构中,我们说了Service层的作用,目前还少加入了一层,DTO(数据传输对象层),该层负责屏蔽后端的实体层,将UI层需要的数据进行重新的定义和封装,在实际的业务场景下,后端实现或存储的数据远比用户需要的数据要庞大和复杂,所

现在以网页发布的软件非常普遍,叫BS模式.前后端分离也是大趋势,或者说逐渐普及开来,深受前后端程序员的喜爱,我还是习惯以程序员来泛称所有软件制作者.后端需要把数据传送给前端,往往是通过DTO的序列化来实现的,而不是直接产生json或xml格式的数据.这里不说为什么要用DTO,只说探讨一个问题,不同的api接口(方法)返回不同格式的数据,这些DTO要如何设计. 特别说明,以下说到的DTO,是指DTO类,而不是DTO实例.虽然O应该是指实例,但这里继续用这个词,不阻碍意思的表述. 方案一,需要什么造

目录 VO(视图模型) 与 DTO(数据传输对象)的区别 1.VO与DTO概念 2.VO 视图模型的必要性与解耦 2.1 视图模型 2.2 视图模型存在的必要性 2.3 视图模型的解耦 3.DTO 存在的必要性 3.1 数据传输对象 3.2 DTO数据传输对象存在的必要性 4. VO与DTO的区别 4.1 DTO = 视图模型 4.2 DTO ≠ 视图模型 5. AutoMapper的使用场景 6. 小结 VO(视图模型) 与 DTO(数据传输对象)的区别 1.VO与DTO概念 VO(View

  什么是领域服务呢?领域服务就是领域对象本身的服务,通常是通过多个聚合以实现单个聚合无法处理的逻辑. 一.领域服务实践 接下来将聚合根Issue中的AssignToAsync()方法[将问题分配给用户],剥离到领域服务当中.如下: // ABP当中的领域服务类通常都是以Manager结尾的 public class IssueManager : DomainService { private readonly IRepository<Issue,Guid> _issueRepository;

Conference架构概述 先贴一下Conference案例的在线地址,UI因为完全拿了微软的实现,所以都是英文的,以后我有空再改为中文的. Conference后台会议管理:http://www.enode.me/conference Conference前台预定座位:http://www.enode.me/registration ENode论坛开源案例:http://www.enode.me/post ENode开源项目地址:https://github.com/tangxuehua/e

阅读目录: 1.开篇介绍 2.尽量使用Lambda匿名函数调用代替反射调用(走进声明式设计) 3.被忽视的特性(Attribute)设计方式 4.扩展方法让你的对象如虎添翼(要学会使用扩展方法的设计思想) 5.别怕Static属性(很多人都怕Static在Service模式下的设计,其实要学会使用线程本地存储(ThreadStatic)) 6.泛型的协变与逆变(设计架构接口(Interface)时要时刻注意对象的协变.逆变) 7.使用泛型的类型推断(还在为参数类型烦恼吗) 8.链式编程(设计符合

阅读目录: 1.背景介绍 2.在业务层中加入核心领域模型(引入DomainModel,让逻辑.数据有家可归,变成一个完整的业务对象) 3.统一协调层Application Layer(加入协调层来转换DomianModel) 4.从数据扁平结构转换成OO体系结构(使用OO丰富代码结构) 5.DomainModel中的内容(带开关的Specification.SOA化的Specification) 6.模式.重构.单元测试在领域模型中的运用 1.背景介绍 由于时间关系废话不多扯了,直奔主题,对领域

环境: vs2015.win7 参考:http://www.cnblogs.com/Erik_Xu/p/5638381.html 生成的help页面如下:,并没有显示控制器和方法. 原因是:新建项目时候没有勾选Web Api,webapi是后来添加的.缺少App_Start下的WebApiConfig.cs文件,如下.要显示Action,更改为 routeTemplate: "api/{controller}/{action}/{id}", public static class We

在前阵子,我对实体框架进行了一定的研究,然后把整个学习的过程开了一个系列,以逐步深入的方式解读实体框架的相关技术,期间每每碰到一些新的问题需要潜入研究.本文继续前面的主题介绍,着重从整体性的来总结一下实体框架的一些方面,希望针对这些实际问题,和大家进行学习交流. 我的整个实体框架的学习和研究,是以我的Winform框架顺利升级到这个实体框架基础上为一个阶段终结,这个阶段事情很多,从开始客运联网售票的WebAPI平台的开发,到微软实体框架的深入研究,以及<基于Metronic的Bootstrap开

.NET框架设计—常被忽视的C#设计技巧 阅读目录: 1.开篇介绍 2.尽量使用Lambda匿名函数调用代替反射调用(走进声明式设计) 3.被忽视的特性(Attribute)设计方式 4.扩展方法让你的对象如虎添翼(要学会使用扩展方法的设计思想) 5.别怕Static属性(很多人都怕Static在Service模式下的设计,其实要学会使用线程本地存储(ThreadStatic)) 6.泛型的协变与逆变(设计架构接口(Interface)时要时刻注意对象的协变.逆变) 7.使用泛型的类型推断(还在

阅读目录: 1.开篇介绍 2.尽量使用Lambda匿名函数调用代替反射调用(走进声明式设计) 3.被忽视的特性(Attribute)设计方式 4.扩展方法让你的对象如虎添翼(要学会使用扩展方法的设计思想) 5.别怕Static属性(很多人都怕Static在Service模式下的设计,其实要学会使用线程本地存储(ThreadStatic)) 6.泛型的协变与逆变(设计架构接口(Interface)时要时刻注意对象的协变.逆变) 7.使用泛型的类型推断(还在为参数类型烦恼吗) 8.链式编程(设计符合

虽然每天的工作都是CURD.还是使用着传统的三层架构.使用着.net Framework,但是这并不能影响我学习DDD和.net core. 总是希望软件在应对复杂多变的场景时能够游刃有余,在解决问题时能够多一种选择. 很早就有关注大神dax.net的NLayerApp系列博文https://www.cnblogs.com/daxnet/category/304141.html 近期入坑.net core,看了进击的辣条的文章Asp.Net Core微服务初体验,很有收获,感谢感谢. 抽时间读了

一.ASP.Net MVC简介 1,什么是ASP.NET MVC? HttpHandler是ASP.net的底层机制,如果直接使用HttpHandler进行开发难度比较大.工作量大.因此提供了ASP.Net MVC. ASP.Net WebForm等高级封装的框架,简化开发,他们的底层仍然是HttpHandler.HttpRequest等 例如:ASP.NET MVC的核心类仍然是实现了IHttpHandler接口的MVCHandler 2,ASP.NET WebForm和ASP.NET MVC

ASP.Net MVC是UI层的框架,EF是数据访问的逻辑. 如果在Controller中using DbContext,把查询的结果的对象放到cshtml中显示,那么一旦在cshtml中访问关联属性,那么就会报错.因为关联属性可以一致关联下去,很诱惑人,include也来不及. 如果不using也没问题,因为会自动回收,但是这打开了“潘多拉魔盒”,甚至可以在UI层更新数据,相当于把数据逻辑写到了UI层. 有的三层架构中用实体类做Model,这样也是不好的,因为实体类属于DAL层的逻辑. 没有最

大致结构: Person(人): id,name,age,bookId Book(书):id,bookName Author(作者):id,authorName,bookId 一个人 只有 一本书,一本书 有多个 作者,一个作者 只出 一本书:(可能举例不好,明白就行) Person ----> Book : OneToOne Book ----> Author: OneToMany 期望达到的效果: sql: select p.id id,p.name,b.bookName bookName

用API开发的人都知道,常用的后台接收参数就是建个DTO,然后前台把这个DTO传过来.后台再更新,例如如下例子: public async Task<IActionResult> PutModel(DTO model) { _context.Entry(model).State = EntityState.Modified; var result = await _context.SaveChangesAsync().ConfigureAwait(false); return OK("

系统架构师-基础到企业应用架构-分层[上篇] 一.前言 大家好,接近一年的时间没有怎么书写博客了,一方面是工作上比较忙,同时生活上也步入正轨,事情比较繁多,目前总算是趋于稳定,可以有时间来完善以前没有写完的系列,也算是对自己这段时间工作和生活上总结,同时也加深下自己对架构和 设计方面的理解,由于本人的写作水平有限,所以在书写的深度和书写的格式上还有很多的缺点,还希望大家多多指出. 二.开篇 本篇我们将针对系统架构中的分层进行讲述,分析不同分层模式的优缺点及应用的场景,当然我们会结合一些案例来介绍

  什么是DDD呢?领域驱动设计[DDD]是一种针对复杂需求的软件开发方法.将软件实现与不断发展的模型联系起来,专注于核心领域逻辑,而不是基础设施细节.DDD适用于复杂领域和大规模应用,而不是简单的CRUD应用.它有助于建立一个灵活.模块化和可维护的代码库. 一.DDD中的领域层和应用层相关概念 DDD主要关注领域层和应用层. 1.DDD中的领域层 领域层中的基本概念有: (1)实体[Entity] 实体就像面向对象中的对象,它包含属性和方法,并且有唯一的ID. (2)值对象[Value Obj

  本文主要介绍了多应用层的问题,包括原因和实现.通过理解介绍了如何区分领域逻辑和应用逻辑,哪些是正确的实践,哪些是不推荐的或者错误的实践. 一.多应用层的问题 1.多应用层介绍   不知道你们是否会遇到一种情况,通过ABP构建了一个后端的API项目,刚开始是为Web端项目(比如,Vue)提供后端接口服务的,随着项目的发展和业务的复杂,增加了移动端的App,或者公众号.小程序等,这样不仅要为Web端提供API服务,而且还需要为移动端的App,或者公众号.小程序等提供API服务.这个场景就是多应用

一.数据库概述 1.什么是数据库?先来看看百度怎么说的. 数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据运行新增.截取.更新.删除等操作.     所谓“数据库”系以一定方式储存在一起.能予多个用户共享.具有尽可能小的冗余度.与应用程序彼此独立的数据集合. 百度的貌似不好理解啊,让我说啊,数据库是存储数据的地方,你这不是废话么?你你你你你说的对,哈哈,存数据的地方是存在哪里呢,存在硬盘上,为什么不是存在内存里面,因为内存无法永久保存.之前我们存数据都是使用的文