领域设计之模型充血、Repository对象注入

  工作中接触了不少项目组,他们在实际的项目开发中,Domain Object的贫血模型设计,还是主要的应用的范式。原因在于,贫血模型模型设计中,把所有涉及持久化的业务逻辑,封装到了Domain Service层或Application Service层,这样的一揽子方案,消除了对某一业务逻辑究竟建在域服务层还是域模型层的争议,使分层简单化了,简单的分层也便于团队协作开发和测试。

  当然,由此带来的问题也不少。

  一、语义不清;

  二、业务复杂易出现不良设计,导致业务重复实现、bug成堆;

  三、事务性业务需求和多任务并发检查易出错;

  四、需求增长、变化带来开发成本快速增长(这比较象面向过程编程了,比较反OO)

  出现的这些问题不解释,相信做过几回项目的或多或少遇到过。

  写了这些,其实可以看出来,潜意识中我是支持使用充血模型的。充血模型可以把业务逻辑做的很薄,完全的业务语义化。在Domain Object层构建CRUD和粒子化的面向Entity的语义实现。(手懒,其实是这个电脑没装IDE,大家可以看这个链接的例子:http://www.cnblogs.com/chenzhao/archive/2012/08/13/2636179.html)

  但是使用充血模型还有两个基本问题需要解决,一个是业务逻辑分层(这个比较烦,时间充裕的时候再写个例子);一个是Domain Object层的Repository注入。

  看下Domain Object层的Repository注入,不说了,看代码:

//Domain Object层
public interface IRoot
{
int id { get; set; }

}
public interface IPersistence<T>
{
IReposity<T> Repository { get; set; }

}
public interface IReposity<T> : IDisposable
{
T Add(T model);
}
public class User : IRoot, IPersistence<User>
{
public int id
{
get;
set;
}

public string Name
{
get;
set;
}

public IReposity<User> Repository
{
get;
set;
}

public void Add()
{
Repository.Add(this);
}
}
//-----------------------

//Domain Service层
public class UserManageService
{
public static void AddUser(User user)
{
user.Persistence().Add();

}
}
public static class UserEx
{
public static User Persistence(this User user)
{
user.Repository = new Repository<User>();
return user;
}
}
//------------------------

//Domain Repository层
public class Repository<T> : IReposity<T>
where T : class,IRoot, new()
{

public T Add(T model)
{
return null;
}

public void Dispose()
{

}
}
//------------------------

  这样就通过服务层,可以向Domain Object 完成Repository Object的注入。当然,你想用第三方依赖注入库也可以,不过不是必选的。(老婆叫吃饭,代码随便搞了下没细看,如有错误你们多包涵。)

  

  

时间: 2025-01-16 16:15:16

领域设计之模型充血、Repository对象注入的相关文章

初探领域驱动设计(2)Repository在DDD中的应用

概述 上一篇我们算是粗略的介绍了一下DDD,我们提到了实体.值类型和领域服务,也稍微讲到了DDD中的分层结构.但这只能算是一个很简单的介绍,并且我们在上篇的末尾还留下了一些问题,其中大家讨论比较多的,也是我本人之前有一些疑问的地方就是Repository.我之前觉得IRepository和三层里面的IDAL很像,为什么要整出这么个东西来:有人说用EF的话就不需要Repository了:IRepository是鸡肋等等. 我觉得这些问题都很好,我自己也觉得有问题,带着这些问题我们就来看一看Repo

设计窘境:来自 Repository 的一丝线索,Domain Model 再重新设计

写在前面 阅读目录: 疑惑解读 设计窘境 一幅图的灵感 为嘛还是你-Repository 后记 上一篇<No zuo no die:DDD 应对具体业务场景,Domain Model 重新设计>. 希望本篇博文废话少点,注:上一篇瞎扯的地方太多. 疑惑解读 先回顾一下,在上一篇博文中,主要阐述的是领域模型的重新设计,包含:真正的去理解领域模型和领域服务的加入(感兴趣的朋友可以看下前几篇来了解一下前因后果.).凡事都有修改的理由,为什么加入领域服务,主要是之前对领域模型的认知不够(实体充当起了伪

.net ef core 领域设计代码转换(上篇)

一.前言 .net core 2.0正式版已经发布几个月了,经过研究,决定把项目转移过来,新手的话可以先看一些官方介绍 传送门:https://docs.microsoft.com/zh-cn/dotnet/core/ 由于在领域设计模型上遇到了一些坑,故给大家分享出来自己的一些解决方案. ok,直接上干货,大概结构如下: 比较教科书式的架构. 二.领域层 领域实体 值对象 规约接口 工作单元接口 仓储接口 聚合跟划分,我们先建立一个简单的用户实体 三.仓储层 引用Microsoft.Entit

[JCIP笔记] (三)如何设计一个线程安全的对象

在当我们谈论线程安全时,我们在谈论什么中,我们讨论了怎样通过Java的synchronize机制去避免几个线程同时访问一个变量时发生问题.忧国忧民的Brian Goetz大神在多年的开发过程中,也悟到了人性的懒惰,他深知许多程序员不会在设计阶段就考虑到线程安全,只是假设自己的代码能按照自己的想法很好地运转.然而当程序上线.线程安全问题真的发生时,要花费多于前期设计数倍的时间和精力去进行排查.解决,甚至重新设计.于是,他在字里行间一直秉持一种"凡事皆可发生"的小心翼翼的哲学,并以这种哲学

从头认识Spring-1.7 怎样通过属性注入Bean?(1)-怎样通过属性向对象注入值?

这一章节我们来讨论一下怎样通过属性注入Bean? 这一章节分为两部分,第一部分我们通过属性向对象注入值,第二部分我们通过属性向对象注入另一个对象的引用. 1.怎样通过属性向对象注入值? (1)domain package com.raylee.my_new_spring.my_new_spring.ch01.topic_1_7; public class Cake { private final int id = index++; private static int index = 0; pr

Codeigniter 利用加密Key(密钥)的对象注入漏洞

http://drops.wooyun.org/papers/1449 原文链接:http://www.mehmetince.net/codeigniter-object-injection-vulnerability-via-encryption-key/ 0x00 背景 大家好,Codeigniter 是我最喜爱的PHP框架之一.和别人一样,我在这个框架中学习了PHP MVC编程.今天,我决定来分析一下Codeigniter的PHP 对象注入漏洞. 我在接下来的叙述中会把重点放在Codeig

解析PHP对象注入漏洞

 0.前言 逛乌云知识库的时候看到一篇有趣的译文:http://drops.wooyun.org/papers/4820. 说的是一种注入方式,叫对象注入.对象也能注入? 是的,只要是存在污染数据,没有什么是不可能注入的,但是这个漏洞有点太古怪了,所以我觉得有趣. 1.原理 在程序编写的时候,往往需要序列化一些运行时数据,所谓序列化就是按照一定的格式将运行时数据写入本地文件.这样做可以对数据进行本地保存,用的时候直接读文件就可以把运行时产生的数据读出.在PHP中就是serialize和uns

struts2将servlet对象注入到Action中

在struts2框架中,可以通过IoC方式将servlet对象注入到Action中,通常需要Action实现以下接口: a. ServletRequestAware: 实现该接口的Action可以直接访问Request对象,该接口中提供void setServletRequest(HttpServletRequest request) 方法,实现此接口的Action控制类通过setServletRequestHttpServlet(HttpServlet request)方法将request对象

设计一个不强引用对象的单例字典

大家都知道,使用NSDictionary存储对象的时候会强引用对象,导致被存储对象的引用计数+1,有时候,我们想用单例来存储对象,但又不希望强引用存储的对象,这该怎么实现呢? 在这里,我们可以使用NSMapTable来实现这个功能. 我直接给出源码: WeakDictionary.h   +   WeakDictionary.m // // WeakDictionary.h // 弱引用字典 // // http://www.cnblogs.com/YouXianMing/ // Copyrig