静态页优秀网站,深圳设计公司vi设计模板,高端品牌网站设计企业网站建设,沈阳网站建设建设公司排名背景领域模型对象只是用来存储应用的数据。业务逻辑位于服务层中#xff0c;管理域对象的数据。在服务层中#xff0c;应用的每个实体对应一个服务类。这种模式大家是不是很熟悉#xff0c;尤其是在中小项目或者项目刚启动的时候#xff0c;都是怎么方便怎么来#xff1b;… 背景领域模型对象只是用来存储应用的数据。业务逻辑位于服务层中管理域对象的数据。在服务层中应用的每个实体对应一个服务类。这种模式大家是不是很熟悉尤其是在中小项目或者项目刚启动的时候都是怎么方便怎么来没错这就是贫血模型。一般画风是这样的。1、Web层接收用户输入将数据传至服务层2、服务层处理业务逻辑、权限管理与授权并与存储层通信using BQoolCommon.Interface.Repository.Dapper;
using BQoolCommon.Interface.Service;
using BQoolCommon.Models.BQoolCommon_SetMain;
using BQoolCommon.Models.Enum;
using BQoolCommon.Models.ViewModel;
using System;
using System.Collections.Generic;
using System.Configuration;namespace BQoolCommon.Service
{public class UserPermissionService : IUserPermissionService{private readonly IInnerSiteMapDapperRep _innerSiteMapDapperRep;private readonly IInnerSiteMapService _innerSiteMapService;private readonly IAccountChannelRelService _accountChannelRelService;private readonly IUserMgmtService _userMgmtService;public UserPermissionService(IInnerSiteMapDapperRep innerSiteMapDapperRep,IInnerSiteMapService innerSiteMapService, IAccountChannelRelService accountChannelRelService, IUserMgmtService userMgmtService){_innerSiteMapDapperRep innerSiteMapDapperRep;_innerSiteMapService innerSiteMapService;_accountChannelRelService accountChannelRelService;_userMgmtService userMgmtService;}
.................................................
3、存储层与数据库进行通信对数据进行持久化using System.Linq;
using BQoolCommon.Interface.Factory;
using BQoolCommon.Interface.Repository.Entity;
using BQoolCommon.Models.BQoolCommon_SetMain;
using BQoolCommon.Models.ViewModel;namespace BQoolCommon.Repository.Entity
{public class WeChatSubscribeEntityRep : GenericEntityRepWeChat_Subscribe, IWeChatSubscribeEntityRep{public WeChatSubscribeEntityRep(IBqoolSetMainDbContextFactory factory) : base(factory){}}
}
问题窥探问题出在了服务层他承受了太多的职责像业务逻辑、权限检查等等这违反了单一职责原则并产生了大量的依赖。当业务复杂度上升时服务层所包含的代码将会非常庞大和复杂。服务层需要包含应用逻辑、用户会话的管理领域层应该包含业务逻辑可以处理与业务相关的会话状态。改进思路我们需要将业务逻辑从服务层移动到领域模型中这样的好处是服务层可以只负责应用逻辑如数据有效性验证、授权检查、开始结束事务等领域模型可以专门负责其相关的业务逻辑。以电商系统来举例架构设计时完全可以针对订单、商品、库存等多个领域模型进行建模相关的业务可以分别放到不同的领域模型中一些很有可能重复的业务代码都会被集中到一处从而降低了复制-粘贴的可能性这就是充血模型。影响充血模型将服务类变得更小使之只负责单一的职责。例如商品的CRUD和其他操作就可以将其放到两个不同的服务类中一个负责商品的CRUD操作另外一个负责与商品相关的其他操作。这样就能使服务类变得小巧、松散、可测试了同时还能降低其他人理解与重用的成本。总结1、从规范和长远来看肯定是充血模型合适些。2、但是如果只是小项目、求快的话当然是开发成本低的贫血模型。
