chisi5619
chisi5619

说说领域驱动设计和贫血、失血、充血模型

这次想讨论的话题是有关领域驱动设计，和领域驱动设计中使用贫血、失血or充血模型的。在这之前我想讨论下当前很多应用的问题，想起这个话题的起因是因为我在InfoQ上面看到这样一篇文章《Spring Web应用的最大瑕疵》，不得不说，这样的标题相当吸引人(′·ω·`)。内容和主要观点大概是这样的，现在大部分应用Spring框架的Java Web应用都相当关注单一职责原则和关注分离原则，但是在此之上却诞生了一些不太好的反模式和设计原则，比如：

  • 领域模型对象只是用来存储应用的数据。(领域模型使用了贫血模型这种反模式)
  • 业务逻辑位于服务层中，管理域对象的数据。
  • 在服务层中，应用的每个实体对应一个服务类。

这类设计原则的应用非常广泛，我现在所在的Java Web项目就是使用这样的设计原则进行架构设计的，基本都是常见的三层或多层架构，他们大概是什么样的呢？

  1. Web层（俗称展现层吧，Presentation Layer)：接收用户输入，将数据传至服务层；
  2. 服务层(Service Layer，可以叫Business Logic Layer)：事务边界，处理业务逻辑、权限管理与授权，并与存储层通信；
  3. 存储层（Data access layer）：与数据库进行通信，对数据进行持久化。

但是发现什么没有？问题出在了服务层，他承受了太多的职责，像事务管理、业务逻辑、权限检查等等，这违反了单一职责原则和关注分离原则，并且产生了大量的依赖和循环依赖。当业务复杂度上升时，服务层所包含的代码将会非常庞大和复杂，直接导致了测试成本的上升。 
我这里正好有个例子，在现在的项目中，负责处理保险业务单的核心类中，包含了4000多行代码，它与数据库中某一关键表相关联，引用（注入）了十几个DAO。在数十个各类方法中，可以处理保单、再保、理赔等等各种不同的业务，同时它还深度依赖于hibernate，不但使用了ORM方法处理数据，甚至还直接用了HQL来获取数据。因为有众多其他服务类与他进行循环引用，项目后期这个庞然大物已经没有人敢轻易改动了，因为谁也不知道他到底都能做什么，重构更是不可能的事。

说了些服务层的坏话，那应该怎么改进呢？

  • 首先，我们需要将业务逻辑从服务层移动到领域模型中，这样的好处是，服务层可以只负责应用逻辑（如数据有效性验证、授权检查、开始结束事务等），领域模型可以专门负责其相关的业务逻辑。还是以之前的保单系统来距离，架构设计时完全可以针对保单、再保、理赔等多个领域模型进行建模，相关的业务可以分别放到不同的领域模型中，一些很有可能重复的业务代码都会被集中到一处，从而降低了复制-粘贴的可能性。
  • 其次，将服务类变得更小，使之只负责单一的职责。文章中有个例子，例如用户账户的CRUD和其他操作，就可以将其放到两个不同的服务类中，一个负责账户的CRUD操作，另外一个负责与用户账户相关的其他操作。

这样就能使服务类变得小巧、松散、可测试了，同时还能降低其他人理解与重用的成本。

接下来的问题就是，在实际的项目中，怎样实践这些设计原则呢？ 
这里有一篇《领域驱动设计和开发实践》非常值得一看，他所推崇的分层结构和上文所述类似，甚至提出了一些更细节的规则：

  • 服务层需要包含应用逻辑、用户会话的管理，但不能包含领域逻辑、业务逻辑和数据访问逻辑；
  • 领域层（领域对象）应该包含业务逻辑，可以处理与业务相关的会话状态.但作为商业应用的核心，应该具有良好的可移植性，不能对特定框架（如Struts、Hibernate、EJB等）产生依赖

说说领域驱动设计和贫血、失血、充血模型_第1张图片

说到这里，终于到了讨论的正题——贫血、失血和充血模型。什么是贫血失血充血模型呢？简单来说

  • 失血模型：模型仅仅包含数据的定义和getter/setter方法，业务逻辑和应用逻辑都放到服务层中。这种类在java中叫POJO，在.NET中叫POCO。
  • 贫血模型：贫血模型中包含了一些业务逻辑，但不包含依赖持久层的业务逻辑。这部分依赖于持久层的业务逻辑将会放到服务层中。可以看出，贫血模型中的领域对象是不依赖于持久层的。
  • 充血模型：充血模型中包含了所有的业务逻辑，包括依赖于持久层的业务逻辑。所以，使用充血模型的领域层是依赖于持久层，简单表示就是UI层->服务层->领域层<->持久层
  • 胀血模型：胀血模型就是把和业务逻辑不想关的其他应用逻辑（如授权、事务等）都放到领域模型中。我感觉胀血模型反而是另外一种的失血模型，因为服务层消失了，领域层干了服务层的事，到头来还是什么都没变。

可以看出来，失血模型和胀血模型都是不可取的，现在的问题是，贫血模型和充血模型哪个更加好一些。很久很久以前，人们针对这个问题进行了旷日持久的争论，最后仍然没有什么结果。这里有一些帖子可供回味： 
贫血，充血模型的解释以及一些经验 
总结一下最近关于domain object以及相关的讨论

双方争论的焦点主要在我上面加粗的两句话上，就是领域模型是否要依赖持久层，因为依赖持久层就意味着单元测试的展开要更加困难（无法脱离框架进行测试，原文的讨论中这里专指Hibernate），领域层就更难独立，将来也更难从应用程序中剥离出来，当然好处是业务逻辑不必混放在不同的层中，使得单一职责性体现的更好。而支持者（充血模型）认为，只要将持久层抽象出来，即可减少测试的困难性，同时适用充血模型毕竟带来了不少开发上的便利性，除了依赖持久层这一点，拥有更多好处的充血模型仍然值得选择。最后，谁也没能说服谁，关于贫血模型和充血模型的选择，更多的要靠具体的业务场景来决定，并不能说哪一种更比哪一种好。设计模式这种东西不是向来都没有什么定论么。

我个人则倾向使用充血模型，因为充血模型更加像一个设计完善的系统架构，好在计算机世界里有很多的IOC和DI框架，唯一的缺陷依赖持久层可以通过各种变通的方法绕过，随着技术的进步，一些缺陷也会被慢慢解决。我的思路是这样的：先将持久层抽象为接口，然后通过服务层将持久层注入到领域模型中，这样领域模型仅仅会依赖于持久层的接口。而这个接口，可以利用现有框架的技术进行抽象。举例来说，Java版Hibernate我了解不多，就以.NET的Entity Framework来说吧：

现在有这么一个DbContext，大家都懂得，DbContext和DbSet是非常不好Mock的两个类（我就是嫌麻烦而已，高手请无视），里面有两个表，一个叫Animes另一个叫Users

说说领域驱动设计和贫血、失血、充血模型_第2张图片

怎样设计接口才能使它既容易使用又可以方便测试呢？直接提取一个接口？DbSet不容易Mock的问题还是没有解决吧。

说说领域驱动设计和贫血、失血、充血模型_第3张图片

好在我们有LINQ和IQueryable，随便改造一下，接口就变成了这样：

说说领域驱动设计和贫血、失血、充血模型_第4张图片

请注意Query()方法，这个方法返回一个IQueryable的对象，而实现了IQueryable的对象是支持LINQ操作的，也就是说，我们可以仍然可以将搜索的Expression交给真正的DbContext来做，而这个DbContext只需要简单一句话：

查询时从 from a in db.Anime.AsQueryable() 改成 from a in db.Query()，一切都解决了。当你在单元测试中想要返回一个假的数据源的时候，直接让FakeDb.Query()方法返回一个拥有假数据的List.AsQueryable()就可以了。这样就实现了领域层和持久层的解耦，毕竟IQueryable是通用的嘛。

转载自：说说领域驱动设计和贫血、失血、充血模型 

-------------------------------------

https://www.evernote.com/shard/s315/sh/a389cb28-9910-443b-8e30-4d1796dafe9d/2838ff81c0a65b966acda644ebb2300d

贫血，充血模型的解释以及一些经验

为了补大家的遗憾，在此总结下ROBBIN的领域模型的一些观点和大家的补充，在网站和演讲中，robbin将领域模型初步分为4大类：
 1，失血模型
 2，贫血模型
 3，充血模型
 4，胀血模型
 那么让我们看看究竟有这些领域模型的具体内容，以及他们的优缺点：

一、失血模型

失血模型简单来说，就是domain object只有属性的getter/setter方法的纯数据类，所有的业务逻辑完全由business object来完成(又称TransactionScript)，这种模型下的domain object被Martin Fowler称之为“贫血的domain object”。下面用举一个具体的代码来说明，代码来自Hibernate的caveatemptor，但经过我的改写：
一个实体类叫做Item，指的是一个拍卖项目 
一个DAO接口类叫做ItemDao 
一个DAO接口实现类叫做ItemDaoHibernateImpl 
一个业务逻辑类叫做ItemManager(或者叫做ItemService)

java代码:  
 
 

 
  1. public class Item implements Serializable {   
  2.      private Long id = null;   
  3.      private int version;   
  4.      private String name;   
  5.      private User seller;   
  6.      private String description;   
  7.      private MonetaryAmount initialPrice;   
  8.      private MonetaryAmount reservePrice;   
  9.      private Date startDate;   
  10.      private Date endDate;   
  11.      private Set categorizedItems = new HashSet();   
  12.      private Collection bids = new ArrayList();   
  13.      private Bid successfulBid;   
  14.      private ItemState state;   
  15.      private User approvedBy;   
  16.      private Date approvalDatetime;   
  17.      private Date created = new Date();   
  18.      //   getter/setter方法省略不写，避免篇幅太长   
  19. }  

 java代码:  
 
 

 
  1. public interface ItemDao {   
  2.      public Item getItemById(Long id);   
  3.      public Collection findAll();   
  4.      public void updateItem(Item item);   
  5. } 

 ItemDao定义持久化操作的接口，用于隔离持久化代码。

java代码:  
 
 

 
  1. public class ItemDaoHibernateImpl implements ItemDao extends HibernateDaoSupport {   
  2.      public Item getItemById(Long id) {   
  3.          return (Item) getHibernateTemplate().load(Item.class, id);   
  4.      }   
  5.      public Collection findAll() {   
  6.          return (List) getHibernateTemplate().find("from Item");   
  7.      }   
  8.      public void updateItem(Item item) {   
  9.          getHibernateTemplate().update(item);   
  10.      }   
  11. } 

 ItemDaoHibernateImpl完成具体的持久化工作，请注意，数据库资源的获取和释放是在ItemDaoHibernateImpl里面处理的，每个DAO方法调用之前打开Session，DAO方法调用之后，关闭Session。(Session放在ThreadLocal中，保证一次调用只打开关闭一次)

java代码:
 

 
  1. public class ItemManager {   
  2.      private ItemDao itemDao;   
  3.      public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}   
  4.      public Bid loadItemById(Long id) {   
  5.          itemDao.loadItemById(id);   
  6.      }   
  7.      public Collection listAllItems() {   
  8.          return   itemDao.findAll();   
  9.      }   
  10.      public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,   
  11.                              Bid currentMaxBid, Bid currentMinBid) throws BusinessException {   
  12.              if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {   
  13.              throw new BusinessException("Bid too low.");   
  14.      }   
  15.       
  16.       // Auction is active   
  17.      if ( !state.equals(ItemState.ACTIVE) )   
  18.              throw new BusinessException("Auction is not active yet.");   
  19.       
  20.       // Auction still valid   
  21.      if ( item.getEndDate().before( new Date() ) )   
  22.              throw new BusinessException("Can't place new bid, auction already ended.");   
  23.       
  24.       // Create new Bid   
  25.      Bid newBid = new Bid(bidAmount, item, bidder);   
  26.       
  27.       // Place bid for this Item   
  28.      item.getBids().add(newBid);   
  29.      itemDao.update(item);      //   调用DAO完成持久化操作   
  30.      return newBid;   
  31.      }   
  32. } 

 


事务的管理是在ItemManger这一层完成的，ItemManager实现具体的业务逻辑。除了常见的和CRUD有关的简单逻辑之外，这里还有一个placeBid的逻辑，即项目的竞标。

以上是一个完整的第一种模型的示例代码。在这个示例中，placeBid，loadItemById，findAll等等业务逻辑统统放在ItemManager中实现，而Item只有getter/setter方法。
 
二、贫血模型

简单来说，就是domain ojbect包含了不依赖于持久化的领域逻辑，而那些依赖持久化的领域逻辑被分离到Service层。 
Service(业务逻辑，事务封装) --> DAO ---> domain object 
这也就是Martin Fowler指的rich domain object :

一个带有业务逻辑的实体类，即domain object是Item 
一个DAO接口ItemDao 
一个DAO实现ItemDaoHibernateImpl 
一个业务逻辑对象ItemManager

java代码:  
 
 

 
  1. public class Item implements Serializable {   
  2.      //   所有的属性和getter/setter方法同上，省略   
  3.      public Bid placeBid(User bidder, MonetaryAmount bidAmount,   
  4.                          Bid currentMaxBid, Bid currentMinBid)   
  5.              throws BusinessException {   
  6.       
  7.               // Check highest bid (can also be a different Strategy (pattern))   
  8.              if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {   
  9.                      throw new BusinessException("Bid too low.");   
  10.              }   
  11.       
  12.               // Auction is active   
  13.              if ( !state.equals(ItemState.ACTIVE) )   
  14.                      throw new BusinessException("Auction is not active yet.");   
  15.       
  16.               // Auction still valid   
  17.              if ( this.getEndDate().before( new Date() ) )   
  18.                      throw new BusinessException("Can't place new bid, auction already ended.");   
  19.       
  20.               // Create new Bid   
  21.              Bid newBid = new Bid(bidAmount, this, bidder);   
  22.       
  23.               // Place bid for this Item   
  24.              this.getBids.add(newBid);   // 请注意这一句，透明的进行了持久化，但是不能在这里调用ItemDao，Item不能对ItemDao产生  
  25.    
  26. 依赖！   
  27.       
  28.               return newBid;   
  29.      }   
  30. } 

 竞标这个业务逻辑被放入到Item中来。请注意this.getBids.add(newBid); 如果没有Hibernate或者JDO这种O/R Mapping的支持，我们是无法实现这种透明的持久化行为的。但是请注意，Item里面不能去调用ItemDAO，对ItemDAO产生依赖！

ItemDao和ItemDaoHibernateImpl的代码同上，省略。

java代码: 
 

 
  1. public class ItemManager {   
  2.      private ItemDao itemDao;   
  3.      public void setItemDao(ItemDao itemDao) { this.itemDao = itemDao;}   
  4.      public Bid loadItemById(Long id) {   
  5.          itemDao.loadItemById(id);   
  6.      }   
  7.      public Collection listAllItems() {   
  8.          return   itemDao.findAll();   
  9.      }   
  10.      public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount,   
  11.                              Bid currentMaxBid, Bid currentMinBid) throws BusinessException {   
  12.          item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid);   
  13.          itemDao.update(item);     // 必须显式的调用DAO，保持持久化   
  14.      }   
  15. } 

 在第二种模型中，placeBid业务逻辑是放在Item中实现的，而loadItemById和findAll业务逻辑是放在ItemManager中实现的。不过值得注意的是，即使placeBid业务逻辑放在Item中，你仍然需要在ItemManager中简单的封装一层，以保证对placeBid业务逻辑进行事务的管理和持久化的触发。
        这种模型是Martin Fowler所指的真正的domain model。在这种模型中，有三个业务逻辑方法：placeBid，loadItemById和findAll，现在的问题是哪个逻辑应该放在Item中，哪个逻辑应该放在ItemManager中。在我们这个例子中，placeBid放在Item中(但是ItemManager也需要对它进行简单的封装)，loadItemById和findAll是放在ItemManager中的。
        切分的原则是什么呢？ Rod Johnson提出原则是“case by case”，可重用度高的，和domain object状态密切关联的放在Item中，可重用度低的，和domain object状态没有密切关联的放在ItemManager中。
        经过上面的讨论，如何区分domain logic和business logic，我想提出一个改进的区分原则：domain logic只应该和这一个domain object的实例状态有关，而不应该和一批domain object的状态有关；当你把一个logic放到domain object中以后，这个domain object应该仍然独立于持久层框架之外(Hibernate,JDO)，这个domain object仍然可以脱离持久层框架进行单元测试，这个domain object仍然是一个完备的，自包含的，不依赖于外部环境的领域对象，这种情况下，这个logic才是domain logic。 
这里有一个很确定的原则：logic是否只和这个object的状态有关，如果只和这个object有关，就是domain logic；如果logic是和一批domain object的状态有关，就不是domain logic，而是business logic。
        Item的placeBid这个业务逻辑方法没有显式的对持久化ItemDao接口产生依赖，所以要放在Item中。请注意，如果脱离了Hibernate这个持久化框架，Item这个domain object是可以进行单元测试的，他不依赖于Hibernate的持久化机制。它是一个独立的，可移植的，完整的，自包含的域对象。而loadItemById和findAll这两个业务逻辑方法是必须显式的对持久化ItemDao接口产生依赖，否则这个业务逻辑就无法完成。如果你要把这两个方法放在Item中，那么Item就无法脱离Hibernate框架，无法在Hibernate框架之外独立存在。 
这种模型的优点： 
1、各层单向依赖，结构清楚，易于实现和维护 
2、设计简单易行，底层模型非常稳定 
这种模型的缺点： 
1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层，显得不够OO 
2、Service层过于厚重

三、充血模型 
        充血模型和第二种模型差不多，所不同的就是如何划分业务逻辑，即认为，绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑)，而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和DAO层打交道。 
Service(事务封装) ---> domain object <---> DAO 
这种模型就是把第二种模型的domain object和business object合二为一了。所以ItemManager就不需要了，在这种模型下面，只有三个类，他们分别是：
Item：包含了实体类信息，也包含了所有的业务逻辑 
ItemDao：持久化DAO接口类 
ItemDaoHibernateImpl：DAO接口的实现类

由于ItemDao和ItemDaoHibernateImpl和上面完全相同，就省略了。

java代码:  
 
 

 
  1. public class Item implements Serializable {   
  2.      //   所有的属性和getter/setter方法都省略   
  3.     private static ItemDao itemDao;   
  4.      public void setItemDao(ItemDao itemDao) {this.itemDao = itemDao;}   
  5.       
  6.       public static Item loadItemById(Long id) {   
  7.          return (Item) itemDao.loadItemById(id);   
  8.      }   
  9.      public static Collection findAll() {   
  10.          return (List) itemDao.findAll();   
  11.      }   
  12.  
  13.      public Bid placeBid(User bidder, MonetaryAmount bidAmount,   
  14.                      Bid currentMaxBid, Bid currentMinBid)   
  15.      throws BusinessException {   
  16.       
  17.           // Check highest bid (can also be a different Strategy (pattern))   
  18.          if (currentMaxBid != null && currentMaxBid.getAmount().compareTo(bidAmount) > 0) {   
  19.                  throw new BusinessException("Bid too low.");   
  20.          }   
  21.           
  22.           // Auction is active   
  23.          if ( !state.equals(ItemState.ACTIVE) )   
  24.                  throw new BusinessException("Auction is not active yet.");   
  25.           
  26.           // Auction still valid   
  27.          if ( this.getEndDate().before( new Date() ) )   
  28.                  throw new BusinessException("Can't place new bid, auction already ended.");   
  29.           
  30.           // Create new Bid   
  31.          Bid newBid = new Bid(bidAmount, this, bidder);   
  32.           
  33.           // Place bid for this Item   
  34.          this.addBid(newBid);   
  35.          itemDao.update(this);       //   调用DAO进行显式持久化   
  36.          return newBid;   
  37.      }   
  38. } 

 在这种模型中，所有的业务逻辑全部都在Item中，事务管理也在Item中实现。
 这种模型的优点： 
1、更加符合OO的原则 
2、Service层很薄，只充当Facade的角色，不和DAO打交道。 
这种模型的缺点： 
1、DAO和domain object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。 
2、如何划分Service层逻辑和domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。 
3、考虑到Service层的事务封装特性，Service层必须对所有的domain object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义一遍所有的domain logic，非常烦琐，而且Service的事务化封装其意义就等于把OO的domain logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在domain层实现的OO在Service层又变成了过程式，对于Web层程序员的角度来看，和贫血模型没有什么区别了。
1.事务我是不希望由Item管理的，而是由容器或更高一层的业务类来管理。
2.如果Item不脱离持久层的管理，如JDO的pm，那么itemDao.update(this); 是不需要的，也就是说Item是在事务过程中从数据库拿出来的，并且声明周期不超出当前事务的范围。
3.如果Item是脱离持久层，也就是在Item的生命周期超出了事务的范围，那就要必须显示调用update或attach之类的持久化方法的，这种时候就应该是按robbin所说的第2种模型来做。
 
四、胀血模型 
        基于充血模型的第三个缺点，有同学提出，干脆取消Service层，只剩下domain object和DAO两层，在domain object的domain logic上面封装事务。 
domain object(事务封装，业务逻辑) <---> DAO 
似乎ruby on rails就是这种模型，他甚至把domain object和DAO都合并了。 
该模型优点： 
1、简化了分层 
2、也算符合OO 
该模型缺点： 
1、很多不是domain logic的service逻辑也被强行放入domain object ，引起了domain ojbect模型的不稳定 
2、domain object暴露给web层过多的信息，可能引起意想不到的副作用。


评价：

        在这四种模型当中，失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说，都已经是可行的了。但是我个人仍然主张使用贫血模型。其理由：

1、参考充血模型第三个缺点，由于暴露给web层程序拿到的还是Service Transaction Script，对于web层程序员来说，底层OO意义丧失了。

2、参考充血模型第三个缺点，为了事务封装，Service层要给每个domain logic提供一个过程化封装，这对于编程来说，做了多余的工作，非
 
常烦琐。

3、domain object和DAO的双向依赖在做大项目中，考虑到团队成员的水平差异，很容易引入不可预知的潜在bug。

4、如何划分domain logic和service logic的标准是不确定的，往往要根据个人经验，有些人就是觉得某个业务他更加贴近domain，也有人认
 
为这个业务是贴近service的。由于划分标准的不确定性，带来的后果就是实际项目中会产生很多这样的争议和纠纷，不同的人会有不同的划分
 
方法，最后就会造成整个项目的逻辑分层混乱。这不像贫血模型中我提出的按照是否依赖持久化进行划分，这种标准是非常确定的，不会引起争议，因此团队开发中，不会产生此类问题。

5、贫血模型的domain object确实不够rich，但是我们是做项目，不是做研究，好用就行了，管它是不是那么纯的OO呢？其实我不同意firebody认为的贫血模型在设计模型和实现代码中有很大跨越的说法。一个设计模型到实现的时候，你直接得到两个类：一个实体类，一个控制类就行了，没有什么跨越。

简单评价一下：

第一种模型绝大多数人都反对，因此反对理由我也不多讲了。但遗憾的是，我观察到的实际情形是，很多使用Hibernate的公司最后都是这种模型，这里面有很大的原因是很多公司的技术水平没有达到这种层次，所以导致了这种贫血模型的出现。从这一点来说，Martin Fowler的批评声音不是太响了，而是太弱了，还需要再继续呐喊。

第二种模型就是Martin Fowler一直主张的模型，实际上也是我一直在实际项目中采用这种模型。我没有看过Martin的POEAA，之所以能够自己摸索到这种模型，也是因为从02年我已经开始思考这个问题并且寻求解决方案了，但是当时没有看到Hibernate，那时候做的一个小型项目我已经按照这种模型来做了，但是由于没有O/R Mapping的支持，写到后来又不得不全部改成贫血的domain object，项目做完以后再继续找，随后就发现了Hibernate。当然，现在很多人一开始就是用Hibernate做项目，没有经历过我经历的那个阶段。
        不过我觉得这种模型仍然不够完美，因为你还是需要一个业务逻辑层来封装所有的domain logic，这显得非常罗嗦，并且业务逻辑对象的接口也不够稳定。如果不考虑业务逻辑对象的重用性的话(业务逻辑对象的可重用性也不可能好)，很多人干脆就去掉了xxxManager这一层，在Web层的Action代码直接调用xxxDao，同时容器事务管理配置到Action这一层上来。Hibernate的caveatemptor就是这样架构的一个典型应用。

第三种模型是我很反对的一种模型，这种模型下面，Domain Object和DAO形成了双向依赖关系，无法脱离框架测试，并且业务逻辑层的服务也和持久层对象的状态耦合到了一起，会造成程序的高度的复杂性，很差的灵活性和糟糕的可维护性。也许将来技术进步导致的O/R Mapping管理下的domain object发展到足够的动态持久透明化的话，这种模型才会成为一个理想的选择。就像O/R Mapping的流行使得第二种模型成为了可能Martin Fowler的Domain Model，或者说我们的第二种模型难道是完美无缺的吗？当然不是，接下来我就要分析一下它的不足，以及可能的解决办法，而这些都来源于我个人的实践探索。

在第二种模型中，我们可以清楚的把这4个类分为三层：

1、实体类层，即Item，带有domain logic的domain object 
2、DAO层，即ItemDao和ItemDaoHibernateImpl，抽象持久化操作的接口和实现类 
3、业务逻辑层，即ItemManager，接受容器事务控制，向Web层提供统一的服务调用在这三层中我们大家可以看到，domain object和DAO都是非常稳定的层，其实原因也很简单，因为domain object是映射数据库字段的，数据库字段不会频繁变动，所以domain object也相对稳定，而面向数据库持久化编程的DAO层也不过就是CRUD而已，不会有更多的花样，所以也很稳定。

问题就在于这个充当business workflow facade的业务逻辑对象，它的变动是相当频繁的。业务逻辑对象通常都是无状态的、受事务控制的、Singleton类，我们可以考察一下业务逻辑对象都有哪几类业务逻辑方法：

第一类：DAO接口方法的代理，就是上面例子中的loadItemById方法和findAll方法。ItemManager之所以要代理这种类，目的有两个：向Web层提供统一的服务调用入口点和给持久化方法增加事务控制功能。这两点都很容易理解，你不能既给Web层程序员提供xxxManager，也给他提供xxxDao，所以你需要用xxxManager封装xxxDao，在这里，充当了一个简单代理功能；而事务控制也是持久化方法必须的，事务可能需要跨越多个DAO方法调用，所以必须放在业务逻辑层，而不能放在DAO层。

但是必须看到，对于一个典型的web应用来说，绝大多数的业务逻辑都是简单的CRUD逻辑，所以这种情况下，针对每个DAO方法，xxxManager都需要提供一个对应的封装方法，这不但是非常枯燥的，也是令人感觉非常不好的。

第二类：domain logic的方法代理。就是上面例子中placeBid方法。虽然Item已经有了placeBid方法，但是ItemManager仍然需要封装一下Item 的placeBid，然后再提供一个简单封装之后的代理方法。这和第一种情况类似，其原因也一样，也是为了给Web层提供一个统一的服务调用入口点和给隐式的持久化动作提供事务控制。同样，和第一种情况一样，针对每个domain logic方法，xxxManager都需要提供一个对应的封装方法，同样是枯燥的，令人不爽的。

第三类：需要多个domain object和DAO参与协作的business workflow。这种情况是业务逻辑对象真正应该完成的职责。
在这个简单的例子中，没有涉及到这种情况，不过大家都可以想像的出来这种应用场景，因此不必举例说明了。

        通过上面的分析可以看出，只有第三类业务逻辑方法才是业务逻辑对象真正应该承担的职责，而前两类业务逻辑方法都是“无奈之举”，不得不为之的事情，不但枯燥，而且令人沮丧。

        分析完了业务逻辑对象，我们再回头看一下domain object，我们要仔细考察一下domain logic的话，会发现domain logic也分为两类：

第一类：需要持久层框架隐式的实现透明持久化的domain logic，例如Item的placeBid方法中的这一句： 
java代码:  
 
 

 
  1. this.getBids().add(newBid); 

上面已经着重提到，虽然这仅仅只是一个Java集合的添加新元素的操作，但是实际上通过事务的控制，会潜在的触发两条SQL：一条是insert一条记录到bid表，一条是更新item表相应的记录。如果我们让Item脱离Hibernate进行单元测试，它就是一个单纯的Java集合操作，如果我们把他加入到Hibernate框架中，他就会潜在的触发两条SQL，这就是隐式的依赖于持久化的domain logic。 
特别请注意的一点是：在没有Hibernate/JDO这类可以实现“透明的持久化”工具出现之前，这类domain logic是无法实现的。对于这一类domain logic，业务逻辑对象必须提供相应的封装方法，以实现事务控制。

第二类：完全不依赖持久化的domain logic，例如readonly例子中的Topic，如下：

java代码:  
 

 
  1.  class Topic {   
  2.      boolean isAllowReply() {   
  3.          Calendar dueDate = Calendar.getInstance();   
  4.          dueDate.setTime(lastUpdatedTime);   
  5.          dueDate.add(Calendar.DATE, forum.timeToLive);   
  6.       
  7.           Date now = new Date();   
  8.          return now.after(dueDate.getTime());   
  9.      }   
  10. } 

 注意这个isAllowReply方法，他和持久化完全不发生一丁点关系。在实际的开发中，我们同样会遇到很多这种不需要持久化的业务逻辑(主要发生在日期运算、数值运算和枚举运算方面)，这种domain logic不管脱离不脱离所在的框架，它的行为都是一致的。对于这种domain logic，业务逻辑层并不需要提供封装方法，它可以适用于任何场合。概括说：action做为控制器 ，service面向use case，domain object是中间稳定的一层，dao是作为下层的服务，提供持久化服务，可以被domain object所使用。

        针对上面帖子中分析的业务逻辑对象的方法有三类的情况，我们在实际的项目中会遇到一些困扰。主要的困扰就是业务逻辑对象的方法会变动的相当频繁，并且业务逻辑对象的方法数量会非常庞大。针对这个问题，我所知道的有两种解决方案，我姑且称之为第二种模型的两类变种：

第一类变种就是partech的那种模型，简单的来说，就是把业务逻辑对象层和DAO层合二为一；第二类变种就是干脆取消业务逻辑层，把事务控制前推至Web层的Action层来处理，下面分别分析一下两类变种的优缺点:
 
第一类变种是合并业务逻辑对象和DAO层，这种设计代码简化为3个类，如下所示：

一个domain object：Item(同第二种模型的代码，省略) 
一个业务层接口：ItemManager(合并原来的ItemManager方法签名和ItemDao接口而来) 
一个业务层实现类：ItemManagerHibernateImpl(合并原来的ItemManager方法实现和ItemDaoHibernateImpl)

java代码:  
 

 
  1. public interface ItemManager {   
  2.      public Item loadItemById(Long id);   
  3.      public Collection findAll();   
  4.      public void updateItem(Item item);   
  5.      public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, Bid currentMaxBid, Bid currentMinBid) throws   
  6.  
  7. BusinessException;   
  8. } 

java代码:  
 

 
  1. public class ItemManagerHibernateImpl implements ItemManager extends HibernateDaoSupport {   
  2.      public Item loadItemById(Long id) {   
  3.          return (Item) getHibernateTemplate().load(Item.class, id);   
  4.      }   
  5.      public   Collection findAll() {   
  6.          return (List) getHibernateTemplate().find("from Item");   
  7.      }   
  8.      public void updateItem(Item item) {   
  9.          getHibernateTemplate().update(item);   
  10.      }   
  11.      public Bid placeBid(Item item, User bidder, MonetaryAmount bidAmount, Bid currentMaxBid, Bid currentMinBid) throws   
  12.  
  13. BusinessException {   
  14.          item.placeBid(bidder, bidAmount, currentMaxBid, currentMinBid);   
  15.          updateItem(item);    //   确保持久化item   
  16.      }   
  17. } 

 第二种模型的第一类变种把业务逻辑对象和DAO层合并到了一起。 
考虑到典型的web应用中，简单的CRUD操作占据了业务逻辑的绝大多数比例，因此第一类变种的优点是：避免了业务逻辑不得不大量封装DAO接口的问题，简化了软件架构设计，节省了大量的业务层代码量。 
这种方案的缺点是：把DAO接口方法和业务逻辑方法混合到了一起，显得职责不够单一化，软件分层结构不够清晰；此外这种方案仍然不得不对隐式依赖持久化的domain logic提供封装方法，未能做到彻底的简化。

总体而言，个人认为这种变种各方面权衡下来，是目前相对最为合理方案，这也是我目前项目中采用的架构。

 第二种模型的第二类变种就是干脆取消ItemManager，保留原来的Item，ItemDao，ItemDaoHibernateImpl这3个类。在这种情况下把事务控制前推至Web层的Action去控制，具体来说，就是直接对Action的execute()方法进行容器事务声明。

这种方式的优点是：极大的简化了业务逻辑层，避免了业务逻辑对象不得不大量封装DAO接口方法和大量封装domain logic的问题。对于业务逻辑非常简单的项目，采用这种方案是一个非常合适的选择。

这种方式的缺点主要有3个：

1) 由于彻底取消了业务逻辑对象层，对于那些有重用需要的、多个domain object和多个DAO参与的、复杂业务逻辑流程来说，你不得不在Action中一遍又一遍的重复实现这部分代码，效率既低，也不利于软件重用。

2) Web层程序员需要对持久层机制有相当高程度的了解和掌握，必须知道什么时候应该调用什么DAO方法进行必要的持久化。

3) 事务的范围被扩大了。假设你在一个Action中，首先需要插入一条记录，然后再需要查询数据库，显示一个记录列表，对于这种情况，事务的作用范围应该是在插入记录的前后，但是现在扩大到了整个execute执行期间。如果插入动作完毕，查询动作过程中出现通往数据库服务器的网络异常，那么前面的插入动作将回滚，但是实际上我们期望的是插入应该被提交。

总体而言，这种变种的缺陷比较大，只适合在业务逻辑非常简单的小型项目中，值得一提的是Hibernate的caveatemptor就是采用这种变种的架构，大家可以参考一下。

综上所述，在采用Rich Domain Object模型的三种解决方案中(第二模型，第二模型第一变种，第二模型第二变种)，我认为权衡下来，第二模型的第一变种是相对最好的解决方案，不过它仍然有一定的不足，在这里我也希望大家能够提出更好的解决方案。
 ，partech 提出了 实体控制对象 和 实体对象 两种不同层次的 Domain Object ，由于 Domain Object 可以依赖于 XXXFinderDAO，因此，也就不存在“大数据量问题”，因此，整个 Domain 体系，对于实际业务表述的更为完整，更为一体化。我非常倾向这种方式。
 一般是这样的顺序： 
Client-->Service-->D Object-->DAO-->DB 
至于哪些该放在哪里，基本有这样的原则：（就是robbin的第二种了） 
DO封装内在的业务逻辑 
Service 封装外在于DO的业务逻辑

当然如果业务逻辑简单或者没有的话也可以： 
Client-->D Object-->DAO-->DB

对于第二种的第一个变种固然是个好办法，但如Robbin所说也有缺陷如果有多个Servcie要调用DAO的话，就有问题了。合并也意味中不能很好的重用。

说到底就是粒度的问题，分得细重用好，但类多、结构复杂、繁琐。分得粗（干脆用一个类干所有的事）重用差，但类少、结构简单。

转载于:https://my.oschina.net/u/1999167/blog/1841997

你可能感兴趣的:(说说领域驱动设计和贫血、失血、充血模型)

  • 情绪觉察日记第37天 露露_e800
    今天是家庭关系规划师的第二阶最后一天，慧萍老师帮我做了个案，帮我处理了埋在心底好多年的一份恐惧，并给了我深深的力量！这几天出来学习，爸妈过来婆家帮我带小孩，妈妈出于爱帮我收拾东西，并跟我先生和婆婆产生矛盾，妈妈觉得他们没有照顾好我…。今晚回家见到妈妈，我很欣赏她并赞扬她，妈妈说今晚要跟我睡我说好，当我们俩躺在床上准备睡觉的时候，我握着妈妈的手对她说:妈妈这几天辛苦你了，你看你多利害把我们的家收拾得
  • 芦花鞋一四 许叶晗
    又是在一个寒冷的夏日里，青铜和葵花决定今天一起去卖芦花鞋，奶奶亲手给他们做了一碗热乎乎的粥对他们说:“就靠你们两挣生活费了这碗粥赶紧趁热喝了吧！”于是青铜和葵花喝完了奶奶给她们做的粥，就准备去镇上卖卢花鞋，这回青铜和葵花穿着新的芦花鞋来到了镇上。青铜这回看到了很多人都在卖，用手势表达对葵花说:“这回有好多人在抢我们生意呢！我们必须得吆喝起来。”葵花点了点头。可是谁知他们也大声的叫，卖芦花喽！卖芦花
  • 关于沟通这件事，项目经理不需要每次都面对面进行 流程大师兄
    很多项目经理都会遇到这样的问题，项目中由于事情太多，根本没有足够的时间去召开会议，那在这种情况下如何去有效地管理项目中的利益相关者？当然，不建议电子邮件也不需要开会的话，建议可以采取下面几种方式来形成有效的沟通，这几种方式可以帮助你努力的通过各种办法来保持和各方面的联系。项目经理首先要问自己几个问题，项目中哪些利益相关者是必须要进行沟通的？可以列出项目中所有的利益相关者清单，同时也整理出项目中哪些
  • 机器学习与深度学习间关系与区别 ℒℴѵℯ心·动ꦿ໊ོ꫞ 人工智能学习深度学习python
    一、机器学习概述定义机器学习（MachineLearning,ML）是一种通过数据驱动的方法，利用统计学和计算算法来训练模型，使计算机能够从数据中学习并自动进行预测或决策。机器学习通过分析大量数据样本，识别其中的模式和规律，从而对新的数据进行判断。其核心在于通过训练过程，让模型不断优化和提升其预测准确性。主要类型1.监督学习（SupervisedLearning）监督学习是指在训练数据集中包含输入
  • 底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说 造命者说
    底层逆袭到底有多难，不甘平凡的你准备好了吗？让吴起给你说说我叫吴起，生于公元前440年的战国初期，正是群雄并起、天下纷争不断的时候。后人说我是军事家、政治家、改革家，是兵家代表人物。评价我一生历仕鲁、魏、楚三国，通晓兵家、法家、儒家三家思想，在内政军事上都有极高的成就。周安王二十一年（公元前381年），因变法得罪守旧贵族，被人乱箭射死。我出生在卫国一个“家累万金”的富有家庭，从年轻时候起就不甘平凡
  • 【iOS】MVC设计模式 Magnetic_h iosmvc设计模式objective-c学习ui
    MVC前言如何设计一个程序的结构，这是一门专门的学问，叫做"架构模式"（architecturalpattern），属于编程的方法论。MVC模式就是架构模式的一种。它是Apple官方推荐的App开发架构，也是一般开发者最先遇到、最经典的架构。MVC各层controller层Controller/ViewController/VC（控制器）负责协调Model和View，处理大部分逻辑它将数据从Mod
  • 一百九十四章. 自相矛盾 巨木擎天
    唉！就这么一夜，林子感觉就像过了很多天似的，先是回了阳间家里，遇到了那么多不可思议的事情儿。特别是小伙伴们，第二次与自己见面时，僵硬的表情和恐怖的气氛，让自己如坐针毡，打从心眼里难受！还有东子，他现在还好吗？有没有被人欺负？护城河里的小鱼小虾们，还都在吗？水不会真的干枯了吧？那对相亲相爱漂亮的太平鸟儿，还好吧！春天了，到了做窝、下蛋、喂养小鸟宝宝的时候了，希望它们都能够平安啊！虽然没有看见家人，也
  • UI学习——cell的复用和自定义cell Magnetic_h ui学习
    目录cell的复用手动（非注册）自动（注册）自定义cellcell的复用在iOS开发中，单元格复用是一种提高表格（UITableView）和集合视图（UICollectionView）滚动性能的技术。当一个UITableViewCell或UICollectionViewCell首次需要显示时，如果没有可复用的单元格，则视图会创建一个新的单元格。一旦这个单元格滚动出屏幕，它就不会被销毁。相反，它被添
  • element实现动态路由+面包屑 软件技术NINI vue案例vue.js前端
    el-breadcrumb是ElementUI组件库中的一个面包屑导航组件，它用于显示当前页面的路径，帮助用户快速理解和导航到应用的各个部分。在Vue.js项目中，如果你已经安装了ElementUI，就可以很方便地使用el-breadcrumb组件。以下是一个基本的使用示例：安装ElementUI（如果你还没有安装的话）:你可以通过npm或yarn来安装ElementUI。bash复制代码npmi
  • 地推话术，如何应对地推过程中家长的拒绝 校师学
    相信校长们在做地推的时候经常遇到这种情况：市场专员反馈家长不接单，咨询师反馈难以邀约这些家长上门，校区地推疲软，招生难。为什么？仅从地推层面分析，一方面因为家长受到的信息轰炸越来越多，对信息越来越“免疫”；而另一方面地推人员的专业能力和营销话术没有提高，无法应对家长的拒绝，对有意向的家长也不知如何跟进，眼睁睁看着家长走远；对于家长的疑问，更不知道如何有技巧地回答，机会白白流失。由于回答没技巧和专业
  • 谢谢你们，爱你们！ 鹿游儿
    昨天家人去泡温泉，二个孩子也带着去，出发前一晚，匆匆下班，赶回家和孩子一起收拾。饭后，我拿出笔和本子（上次去澳门时做手帐的本子）写下了1\2\3\4\5\6\7\8\9,让后让小壹去思考，带什么出发去旅游呢？她在对应的数字旁边画上了，泳衣、泳圈、肖恩、内衣内裤、tapuy、拖鞋……画完后，就让她自己对着这个本子，将要带的，一一带上，没想到这次带的书还是这本《便便工厂》(晚上姑婆发照片过来，妹妹累得
  • C语言如何定义宏函数？ 小九格物 c语言
    在C语言中，宏函数是通过预处理器定义的，它在编译之前替换代码中的宏调用。宏函数可以模拟函数的行为，但它们不是真正的函数，因为它们在编译时不会进行类型检查，也不会分配存储空间。宏函数的定义通常使用#define指令，后面跟着宏的名称和参数列表，以及宏展开后的代码。宏函数的定义方式：1.基本宏函数：这是最简单的宏函数形式，它直接定义一个表达式。#defineSQUARE(x)((x)*(x))2.带参
  • 微服务下功能权限与数据权限的设计与实现 nbsaas-boot 微服务java架构
    在微服务架构下，系统的功能权限和数据权限控制显得尤为重要。随着系统规模的扩大和微服务数量的增加，如何保证不同用户和服务之间的访问权限准确、细粒度地控制，成为设计安全策略的关键。本文将讨论如何在微服务体系中设计和实现功能权限与数据权限控制。1.功能权限与数据权限的定义功能权限：指用户或系统角色对特定功能的访问权限。通常是某个用户角色能否执行某个操作，比如查看订单、创建订单、修改用户资料等。数据权限：
  • 理解Gunicorn：Python WSGI服务器的基石 范范0825 ipythonlinux运维
    理解Gunicorn：PythonWSGI服务器的基石介绍Gunicorn，全称GreenUnicorn，是一个为PythonWSGI（WebServerGatewayInterface）应用设计的高效、轻量级HTTP服务器。作为PythonWeb应用部署的常用工具，Gunicorn以其高性能和易用性著称。本文将介绍Gunicorn的基本概念、安装和配置，帮助初学者快速上手。1.什么是Gunico
  • 2021年12月19日，春蕾教育集团团建活动感受——黄晓丹 黄错错加油
    感受:1.从陌生到熟悉的过程。游戏环节让我们在轻松的氛围中得到了锻炼，也增长了不少知识。2.游戏过程中，我们贡献的是个人力量，展现的是团队的力量。它磨合的往往不止是工作的熟悉，更是观念上契合度的贴近。3.这和工作是一样的道理。在各自的岗位上，每个人摆正自己的位置、各司其职充分发挥才能，并团结一致劲往一处使，才能实现最大的成功。新知:1.团队精神需要不断地创新。过去，人们把创新看作是冒风险，现在人们
  • Cell Insight | 单细胞测序技术又一新发现，可用于HIV-1和Mtb共感染个体诊断 尐尐呅
    结核病是艾滋病合并其他疾病中导致患者死亡的主要原因。其中结核病由结核分枝杆菌（Mycobacteriumtuberculosis,Mtb）感染引起，获得性免疫缺陷综合症（艾滋病）由人免疫缺陷病毒（Humanimmunodeficiencyvirustype1,HIV-1）感染引起。国家感染性疾病临床医学研究中心/深圳市第三人民医院张国良团队携手深圳华大生命科学研究院吴靓团队，共同研究得出单细胞测序
  • c++ 的iostream 和 c++的stdio的区别和联系 黄卷青灯77 c++算法开发语言iostreamstdio
    在C++中，iostream和C语言的stdio.h都是用于处理输入输出的库，但它们在设计、用法和功能上有许多不同。以下是两者的区别和联系：区别1.编程风格iostream（C++风格）：C++标准库中的输入输出流类库，支持面向对象的输入输出操作。典型用法是cin（输入）和cout（输出），使用>操作符来处理数据。更加类型安全，支持用户自定义类型的输入输出。#includeintmain(){in
  • 《投行人生》读书笔记 小蘑菇的树洞
    《投行人生》----作者詹姆斯-A-朗德摩根斯坦利副主席40年的职业洞见-很短小精悍的篇幅，比较适合初入职场的新人。第一部分成功的职业生涯需要规划1.情商归为适应能力分享与协作同理心适应能力，更多的是自我意识，你有能力识别自己的情并分辨这些情绪如何影响你的思想和行为。2.对于初入职场的人的建议，细节，截止日期和数据很重要截止日期，一种有效的方法是请老板为你所有的任务进行优先级排序。和老板喝咖啡的好
  • Linux下QT开发的动态库界面弹出操作（SDL2） 13jjyao QT类qt开发语言sdl2linux
    需求：操作系统为linux，开发框架为qt，做成需带界面的qt动态库，调用方为java等非qt程序难点：调用方为java等非qt程序，也就是说调用方肯定不带QApplication::exec()，缺少了这个，QTimer等事件和QT创建的窗口将不能弹出(包括opencv也是不能弹出)；这与qt调用本身qt库是有本质的区别的思路：1.调用方缺QApplication::exec()，那么我们在接口
  • 绘本讲师训练营【24期】8/21阅读原创《独生小孩》 1784e22615e0
    24016-孟娟《独生小孩》图片发自App今天我想分享一个蛮特别的绘本，讲的是一个特殊的群体，我也是属于这个群体，80后的独生小孩。这是一本中国绘本，作者郭婧，也是一个80厚。全书一百多页，均为铅笔绘制，虽然为黑白色调，但并不显得沉闷。全书没有文字，犹如“默片”，但并不影响读者对该作品的理解，反而显得神秘，梦幻，給读者留下想象的空间。作者在前蝴蝶页这样写到：“我更希望父母和孩子一起分享这本书，使他
  • 店群合一模式下的社区团购新发展——结合链动 2+1 模式、AI 智能名片与 S2B2C 商城小程序源码 说私域 人工智能小程序
    摘要：本文探讨了店群合一的社区团购平台在当今商业环境中的重要性和优势。通过分析店群合一模式如何将互联网社群与线下终端紧密结合，阐述了链动2+1模式、AI智能名片和S2B2C商城小程序源码在这一模式中的应用价值。这些创新元素的结合为社区团购带来了新的机遇，提升了用户信任感、拓展了营销渠道，并实现了线上线下的完美融合。一、引言随着互联网技术的不断发展，社区团购作为一种新兴的商业模式，在满足消费者日常需
  • 消息中间件有哪些常见类型 xmh-sxh-1314 java
    消息中间件根据其设计理念和用途，可以大致分为以下几种常见类型：点对点消息队列（Point-to-PointMessagingQueues）：在这种模型中，消息被发送到特定的队列中，消费者从队列中取出并处理消息。队列中的消息只能被一个消费者消费，消费后即被删除。常见的实现包括IBM的MQSeries、RabbitMQ的部分使用场景等。适用于任务分发、负载均衡等场景。发布/订阅消息模型（Pub/Sub
  • ArcGIS栅格计算器常见公式（赋值、0和空值的转换、补充栅格空值） 研学随笔 arcgis经验分享
    我们在使用ArcGIS时通常经常用到栅格计算器，今天主要给大家介绍我日常中经常用到的几个公式，供大家参考学习。将特定值（-9999）赋值为0，例如-9999.Con("raster"==-9999,0,"raster")2.给空值赋予特定的值（如0）Con(IsNull("raster"),0,"raster")3.将特定的栅格值(如1)赋值为空值，其他保留原值SetNull("raster"==
  • 那个抄袭的大张伟 猫小努
    最近一直在追《即刻电音》这个综艺，除了觉得出场节目的音乐制作人有意思之外，也觉得有两个导师挺有趣的（另外一个就忽略了吧）。孙艺兴在上一篇文章里面已经说过了，那么这篇就说说我们的大老师，大张伟吧。其实在节目刚开始大张伟出来的时候，我以为他是属于导师里面来活跃气氛负责搞笑的，毕竟孙艺兴属于卖萌卖傻卖老实的，尚雯婕一般负责装逼耍狠的，而大张伟一贯以来上综艺的形象基本上都是蹦蹦跳跳带动气氛的。谁知道，两期
  • 水平垂直居中的几种方法（总结） LJ小番茄 CSS_玄学语言htmljavascript前端csscss3
    1.使用flexbox的justify-content和align-items.parent{display:flex;justify-content:center;/*水平居中*/align-items:center;/*垂直居中*/height:100vh;/*需要指定高度*/}2.使用grid的place-items:center.parent{display:grid;place-item
  • 本周第二次约练 2cfbdfe28a51
    中原焦点团队中24初26刘霞2021.12.3约练161次，分享第368天当事人虽然是带着问题来的，但是咨询过程中发现，她是经过自己不断地调整和努力才走到现在的，看到当事人的不容易，找到例外，发现资源，力量感也就随之而来。增强画面感，或者说重温，会给当事人带来更深刻的感受。
  • 放下是一段成长的修行 小莳玥
    人来到这个世界上，只有两件事：生和死。一件事已经做完了，另一件你还急什么呢?是人，都有七情六欲。是心，都有喜怒哀乐，这些再正常不过了。别总抱怨自己活得累，过得辛苦。永远记住：舒坦是留给死人的。苦，才是生活；累，才是工作；变，才是命运；忍，才是历练；容，才是智慧；静，才是修养；舍，才会得到；做，才会拥有。人生，活得太清楚，才是最大的不明白。有些事，看得很清，却说不清；有些人，了解很深，却猜不透；有些
  • 回溯 Leetcode 332 重新安排行程 mmaerd Leetcode刷题学习记录leetcode算法职场和发展
    重新安排行程Leetcode332学习记录自代码随想录给你一份航线列表tickets，其中tickets[i]=[fromi,toi]表示飞机出发和降落的机场地点。请你对该行程进行重新规划排序。所有这些机票都属于一个从JFK（肯尼迪国际机场）出发的先生，所以该行程必须从JFK开始。如果存在多种有效的行程，请你按字典排序返回最小的行程组合。例如，行程[“JFK”,“LGA”]与[“JFK”,“LGB
  • Python数据分析与可视化实战指南 William数据分析 pythonpython数据
    在数据驱动的时代，Python因其简洁的语法、强大的库生态系统以及活跃的社区，成为了数据分析与可视化的首选语言。本文将通过一个详细的案例，带领大家学习如何使用Python进行数据分析，并通过可视化来直观呈现分析结果。一、环境准备1.1安装必要库在开始数据分析和可视化之前，我们需要安装一些常用的库。主要包括pandas、numpy、matplotlib和seaborn等。这些库分别用于数据处理、数学
  • 每日一题——第八十四题 互联网打工人no1 C语言程序设计每日一练c语言
    题目：编写函数1、输入10个职工的姓名和职工号2、按照职工由大到小顺序排列，姓名顺序也随之调整3、要求输入一个职工号，用折半查找法找出该职工的姓名#define_CRT_SECURE_NO_WARNINGS#include#include#defineMAX_EMPLOYEES10typedefstruct{intid;charname[50];}Empolyee;voidinputEmploye
  • Hadoop(一) 朱辉辉33 hadooplinux
    今天在诺基亚第一天开始培训大数据，因为之前没接触过Linux，所以这次一起学了，任务量还是蛮大的。 首先下载安装了Xshell软件，然后公司给了账号密码连接上了河南郑州那边的服务器，接下来开始按照给的资料学习，全英文的，头也不讲解，说锻炼我们的学习能力，然后就开始跌跌撞撞的自学。这里写部分已经运行成功的代码吧.    在hdfs下，运行hadoop fs -mkdir /u
  • maven An error occurred while filtering resources blackproof maven报错
    转：http://stackoverflow.com/questions/18145774/eclipse-an-error-occurred-while-filtering-resources   maven报错： maven An error occurred while filtering resources   Maven -> Update Proje
  • jdk常用故障排查命令 daysinsun jvm
    linux下常见定位命令： 1、jps      输出Java进程       -q       只输出进程ID的名称，省略主类的名称；       -m      输出进程启动时传递给main函数的参数；     &nb
  • java 位移运算与乘法运算 周凡杨 java位移运算乘法
      对于 JAVA 编程中，适当的采用位移运算，会减少代码的运行时间，提高项目的运行效率。这个可以从一道面试题说起：     问题： 用最有效率的方法算出2 乘以8 等於几?” 答案：2 << 3 由此就引发了我的思考，为什么位移运算会比乘法运算更快呢？其实简单的想想，计算机的内存是用由 0 和 1 组成的二
  • java中的枚举(enmu) g21121 java
    从jdk1.5开始，java增加了enum(枚举)这个类型，但是大家在平时运用中还是比较少用到枚举的，而且很多人和我一样对枚举一知半解，下面就跟大家一起学习下enmu枚举。先看一个最简单的枚举类型，一个返回类型的枚举： public enum ResultType { /** * 成功 */ SUCCESS, /** * 失败 */ FAIL,
  • MQ初级学习 510888780 activemq
    1.下载ActiveMQ 去官方网站下载：http://activemq.apache.org/ 2.运行ActiveMQ 解压缩apache-activemq-5.9.0-bin.zip到C盘，然后双击apache-activemq-5.9.0-\bin\activemq-admin.bat运行ActiveMQ程序。 启动ActiveMQ以后，登陆：http://localhos
  • Spring_Transactional_Propagation 布衣凌宇 springtransactional
    //事务传播属性 @Transactional(propagation=Propagation.REQUIRED)//如果有事务，那么加入事务，没有的话新创建一个 @Transactional(propagation=Propagation.NOT_SUPPORTED)//这个方法不开启事务 @Transactional(propagation=Propagation.REQUIREDS_N
  • 我的spring学习笔记12-idref与ref的区别 aijuans spring
    idref用来将容器内其他bean的id传给<constructor-arg>/<property>元素，同时提供错误验证功能。例如： <bean id ="theTargetBean" class="..." /> <bean id ="theClientBean" class=&quo
  • Jqplot之折线图 antlove jsjqueryWebtimeseriesjqplot
    timeseriesChart.html <script type="text/javascript" src="jslib/jquery.min.js"></script> <script type="text/javascript" src="jslib/excanvas.min.js&
  • JDBC中事务处理应用 百合不是茶 javaJDBC编程事务控制语句
      解释事务的概念; 事务控制是sql语句中的核心之一;事务控制的作用就是保证数据的正常执行与异常之后可以恢复   事务常用命令:             Commit提交         
  • [转]ConcurrentHashMap Collections.synchronizedMap和Hashtable讨论 bijian1013 java多线程线程安全HashMap
    在Java类库中出现的第一个关联的集合类是Hashtable，它是JDK1.0的一部分。 Hashtable提供了一种易于使用的、线程安全的、关联的map功能，这当然也是方便的。然而，线程安全性是凭代价换来的――Hashtable的所有方法都是同步的。此时，无竞争的同步会导致可观的性能代价。Hashtable的后继者HashMap是作为JDK1.2中的集合框架的一部分出现的，它通过提供一个不同步的
  • ng-if与ng-show、ng-hide指令的区别和注意事项 bijian1013 JavaScriptAngularJS
            angularJS中的ng-show、ng-hide、ng-if指令都可以用来控制dom元素的显示或隐藏。ng-show和ng-hide根据所给表达式的值来显示或隐藏HTML元素。当赋值给ng-show指令的值为false时元素会被隐藏，值为true时元素会显示。ng-hide功能类似，使用方式相反。元素的显示或
  • 【持久化框架MyBatis3七】MyBatis3定义typeHandler bit1129 TypeHandler
    什么是typeHandler? typeHandler用于将某个类型的数据映射到表的某一列上，以完成MyBatis列跟某个属性的映射   内置typeHandler MyBatis内置了很多typeHandler，这写typeHandler通过org.apache.ibatis.type.TypeHandlerRegistry进行注册，比如对于日期型数据的typeHandler，
  • 上传下载文件rz,sz命令 bitcarter linux命令rz
    刚开始使用rz上传和sz下载命令： 因为我们是通过secureCRT终端工具进行使用的所以会有上传下载这样的需求： 我遇到的问题： sz下载A文件10M左右，没有问题 但是将这个文件A再传到另一天服务器上时就出现传不上去，甚至出现乱码，死掉现象，具体问题 解决方法： 上传命令改为;rz -ybe 下载命令改为：sz -be filename 如果还是有问题： 那就是文
  • 通过ngx-lua来统计nginx上的虚拟主机性能数据 ronin47 ngx-lua　统计 解禁ip
    介绍 以前我们为nginx做统计,都是通过对日志的分析来完成.比较麻烦,现在基于ngx_lua插件,开发了实时统计站点状态的脚本,解放生产力.项目主页: https://github.com/skyeydemon/ngx-lua-stats 功能 支持分不同虚拟主机统计, 同一个虚拟主机下可以分不同的location统计. 可以统计与query-times request-time
  • java-68-把数组排成最小的数。一个正整数数组，将它们连接起来排成一个数，输出能排出的所有数字中最小的。例如输入数组{32, 321}，则输出32132 bylijinnan java
    import java.util.Arrays; import java.util.Comparator; public class MinNumFromIntArray { /** * Q68输入一个正整数数组，将它们连接起来排成一个数，输出能排出的所有数字中最小的一个。 * 例如输入数组{32, 321}，则输出这两个能排成的最小数字32132。请给出解决问题
  • Oracle基本操作 ccii Oracle SQL总结Oracle SQL语法Oracle基本操作Oracle SQL
    一、表操作 1. 常用数据类型 NUMBER(p,s)：可变长度的数字。p表示整数加小数的最大位数，s为最大小数位数。支持最大精度为38位 NVARCHAR2(size)：变长字符串，最大长度为4000字节（以字符数为单位） VARCHAR2(size)：变长字符串，最大长度为4000字节（以字节数为单位） CHAR(size)：定长字符串，最大长度为2000字节，最小为1字节，默认
  • [强人工智能]实现强人工智能的路线图 comsci 人工智能
        1：创建一个用于记录拓扑网络连接的矩阵数据表      2:自动构造或者人工复制一个包含10万个连接(1000*1000)的流程图      3：将这个流程图导入到矩阵数据表中      4：在矩阵的每个有意义的节点中嵌入一段简单的
  • 给Tomcat，Apache配置gzip压缩(HTTP压缩)功能 cwqcwqmax9 apache
    背景： HTTP 压缩可以大大提高浏览网站的速度，它的原理是，在客户端请求网页后，从服务器端将网页文件压缩，再下载到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML ,CSS,Javascript , Text ，它可以节省40%左右的流量。更为重要的是，它可以对动态生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩，
  • SpringMVC and Struts2 dashuaifu struts2springMVC
    SpringMVC VS Struts2 1: spring3开发效率高于struts 2: spring3 mvc可以认为已经100%零配置 3: struts2是类级别的拦截， 一个类对应一个request上下文， springmvc是方法级别的拦截，一个方法对应一个request上下文，而方法同时又跟一个url对应 所以说从架构本身上 spring3 mvc就容易实现r
  • windows常用命令行命令 dcj3sjt126com windowscmdcommand
    在windows系统中，点击开始－运行，可以直接输入命令行，快速打开一些原本需要多次点击图标才能打开的界面，如常用的输入cmd打开dos命令行，输入taskmgr打开任务管理器。此处列出了网上搜集到的一些常用命令。winver 检查windows版本 wmimgmt.msc 打开windows管理体系结构(wmi) wupdmgr windows更新程序 wscrip
  • 再看知名应用背后的第三方开源项目 dcj3sjt126com ios
    知名应用程序的设计和技术一直都是开发者需要学习的，同样这些应用所使用的开源框架也是不可忽视的一部分。此前《 iOS第三方开源库的吐槽和备忘》中作者ibireme列举了国内多款知名应用所使用的开源框架，并对其中一些框架进行了分析，同样国外开发者 @iOSCowboy也在博客中给我们列出了国外多款知名应用使用的开源框架。另外txx's blog中详细介绍了 Facebook Paper使用的第三
  • Objective-c单例模式的正确写法 jsntghf 单例iosiPhone
    一般情况下，可能我们写的单例模式是这样的： #import <Foundation/Foundation.h> @interface Downloader : NSObject + (instancetype)sharedDownloader; @end #import "Downloader.h" @implementation
  • jquery easyui datagrid 加载成功，选中某一行 hae jqueryeasyuidatagrid数据加载
    1.首先你需要设置datagrid的onLoadSuccess $( '#dg' ).datagrid({onLoadSuccess :  function (data){      $( '#dg' ).datagrid( 'selectRow' ,3); }});   2.onL
  • jQuery用户数字打分评价效果 ini JavaScripthtmljqueryWebcss
    效果体验：http://hovertree.com/texiao/jquery/5.htmHTML文件代码： <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>jQuery用户数字打分评分代码 - HoverTree</
  • mybatis的paramType kerryg DAOsql
    MyBatis传多个参数： 1、采用#{0},#{1}获得参数：    Dao层函数方法：     public User selectUser(String name,String area); 对应的Mapper.xml    <select id="selectUser" result
  • centos 7安装mysql5.5 MrLee23 centos
    首先centos7 已经不支持mysql，因为收费了你懂得，所以内部集成了mariadb，而安装mysql的话会和mariadb的文件冲突，所以需要先卸载掉mariadb，以下为卸载mariadb，安装mysql的步骤。   #列出所有被安装的rpm package rpm -qa | grep mariadb   #卸载 rpm -e mariadb-libs-5.
  • 利用thrift来实现消息群发 qifeifei thrift
               Thrift项目一般用来做内部项目接偶用的，还有能跨不同语言的功能，非常方便，一般前端系统和后台server线上都是3个节点，然后前端通过获取client来访问后台server，那么如果是多太server，就是有一个负载均衡的方法，然后最后访问其中一个节点。那么换个思路，能不能发送给所有节点的server呢，如果能就
  • 实现一个sizeof获取Java对象大小 teasp javaHotSpot内存对象大小sizeof
       由于Java的设计者不想让程序员管理和了解内存的使用，我们想要知道一个对象在内存中的大小变得比较困难了。本文提供了可以获取对象的大小的方法，但是由于各个虚拟机在内存使用上可能存在不同，因此该方法不能在各虚拟机上都适用，而是仅在hotspot 32位虚拟机上，或者其它内存管理方式与hotspot 32位虚拟机相同的虚拟机上 适用。     
  • SVN错误及处理 xiangqian0505 SVN提交文件时服务器强行关闭
    在SVN服务控制台打开资源库“SVN无法读取current” ---摘自网络 写道 SVN无法读取current修复方法 Can't read file : End of file found 文件：repository/db/txn_current、repository/db/current   其中current记录当前最新版本号，txn_current记录版本库中版本
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他