首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    Rafy 领域实体框架 - 领域模型设计器(建模工具)设计方案

    去年4月,我们为 Rafy 框架添加了领域模型设计器组件。时隔一年,谨以本文,简要说明该领域模型设计器的设计思想。 设计目标 Rafy 实体框架中以领域驱动设计作为指导思想。所以在开发时,以领域建模为首要任务。为此,我们为它开发了领域模型设计器。开发人员可以在设计器中,设计相应的领域模型,查看现有代码对应的领域模型。 我们为这个设计器制定了以下功能: 外部简单设计器:也就是设计器可以部署为一个可以独立运行的软件。该软件可以打开领域模型的设计图,方便团队中的非开发人员角色查看。同样,这个软件最好也能支

    010

    “领域驱动开发”实例之旅(1)--不一样的开发模式      一、分析业务需求。    二、设计领域对象模型    三、测试领域对象模型    四、设计业务处理类    五、设计Entity和Vi

    听说DDD-“领域驱动开发”已经很久了,园子里面已经有不少大牛写过博文介绍,但我一直没有尝试过,直到今年公司的一个项目出现数据库移植,原来的业务逻辑都写在SqlServer的存储过程中,现在要移植到PostgreSQL中,才真切的体会到,再继续走“表驱动开发”的模式,没有好前途了。于是,花了几个星期,来实践一下领域驱动开发这种开发模式。      征得《领域对象驱动开发:来吧,让我们从对象开始吧》原文作者的同意,我选择文中的“超市收银”业务场景,开发了一个“超市管理系统”--PDF.NET Supe

    07

    领域建模之数据模型设计方法论

    开发人员在日常工作中,参与PRD评审、听产品经理讲述用户故事、提出各种需求。评审结束,一般会一股脑投入到设计开发,而数据库表设计就是其中不可或缺的一个过程。对于熟悉的业务模块,通过对需求分析,可以轻而易举的完成数据表设计,但对于非熟悉业务领域,可能会经过多轮PRD分析,整理一套数据表结构基础,然后对其追加字段,就完成了基础的数据模型设计。而在这个过程中,往往会感觉没有可以参考的理论,有时候甚至对设计的数据库表产生怀疑,不断考虑此设计是否符合业务、表结构设计后期是否具有通用性、表之间关系是否恰当可扩展等等。今天来谈些在实际业务开发中,针对数据建模的一些思考。

    01

    C#复杂XML反序列化为实体对象两种方式

    今天主要讲的是如何把通过接口获取到的Xml数据转换成(反序列化)我们想要的实体对象,当然Xml反序列化和Json反序列化的方式基本上都是大同小异。都是我们事先定义好对应的对应的Xml实体模型,不过Xml是通过XmlSerializer类的相关特性来对实体对象和 XML文档之间进行序列化和反序列化操作的。序列化和反序列化其实都还好,我们可以调用封装好的XmlHelper帮助类即可实现,最关键的是我们该如何去定义这些实体模型(Model)。当你遇到对方接口一下子返回一大串的Xml数据并且里面存在很多不同的Xml节点,你该怎么办一个一个去解析这些节点到模型上去吗?本文我主要讲两种方式,第一种方法是通过手写的方式去定义Xml的实体对象模型类,第二种方法是通过Visual Studio自带的生成Xml实体对象模型类。

    00

    C#复杂XML反序列化为实体对象两种方式

    今天主要讲的是如何把通过接口获取到的Xml数据转换成(反序列化)我们想要的实体对象,当然Xml反序列化和Json反序列化的方式基本上都是大同小异。都是我们事先定义好对应的对应的Xml实体模型,不过Xml是通过XmlSerializer类的相关特性来对实体对象和 XML文档之间进行序列化和反序列化操作的。序列化和反序列化其实都还好,我们可以调用封装好的XmlHelper帮助类即可实现,最关键的是我们该如何去定义这些实体模型(Model)。当你遇到对方接口一下子返回一大串的Xml数据并且里面存在很多不同的Xml节点,你该怎么办一个一个去解析这些节点到模型上去吗?本文我主要讲两种方式,第一种方法是通过手写的方式去定义Xml的实体对象模型类,第二种方法是通过Visual Studio自带的生成Xml实体对象模型类。

    02

    Java中常见的对象类型简述(DO、BO、DTO、VO、AO、PO)

    VO(View Object):视图对象,用于展示层,它的作用是把某个指定页面(或组件)的所有数据封装起来。 DTO(Data Transfer Object):数据传输对象,这个概念来源于J2EE的设计模式,原来的目的是为了EJB的分布式应用提供粗粒度的数据实体,以减少分布式调用的次数,从而提高分布式调用的性能和降低网络负载,但在这里,我泛指用于展示层与服务层之间的数据传输对象。 DO(Domain Object):领域对象,就是从现实世界中抽象出来的有形或无形的业务实体。 PO(Persistent Object):持久化对象,它跟持久层(通常是关系型数据库)的数据结构形成一一对应的映射关系,如果持久层是关系型数据库,那么,数据表中的每个字段(或若干个)就对应PO的一个(或若干个)属性。 BO(business object):业务对象,主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。 AO( Application Object):应用对象,在Web层与Service层之间抽象的复用对象模型,极为贴近展示层,复用度不高。

    01
    领券