[原创]实例-少用单例及降低耦合_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > [原创]实例-少用单例及降低耦合

[原创]实例-少用单例及降低耦合

 2015/1/4 13:10:32  Gods_巨蚁  程序员俱乐部  我要评论(0)
  • 摘要:引言我想就我个人开发时遇到的一些实际情况,与各位做一些分享,语言以c#、java为例,代码遵循语言编码规范实例本文以某.net客户端项目A为例,在项目A中,数据访问层存在如下多个服务模块1、各服务内聚了数据处理逻辑,并提供简单的接口供上层业务逻辑调用2、各个服务间存在相互调用的情况为便于上层访问各数据服务,一些程序员会将每个服务都定位为单例,或许会习惯性的命名为XxxManager服务间的应用,如服务A依赖服务B提供数据,不假思索的使用BSerivice.Instance.Xxx(
  • 标签:原创 实例

引言

我想就我个人开发时遇到的一些实际情况,与各位做一些分享,语言以c#、java为例,代码遵循语言编码规范

实例

本文以某.net客户端项目A为例,在项目A中,数据访问层存在如下多个服务模块 1、各服务内聚了数据处理逻辑,并提供简单的接口供上层业务逻辑调用 2、各个服务间存在相互调用的情况     为便于上层访问各数据服务,一些程序员会将每个服务都定位为单例,或许会习惯性的命名为XxxManager 服务间的应用,如服务A依赖服务B提供数据,不假思索的使用BSerivice.Instance.Xxx()获取数据 对于小型项目,这样做无可厚非,随着软件的复杂度的提升,这样的结构难免会造成维护上的苦难。过多全局实例,服务间的强耦合,自然散发出不佳的味道   那么如何改善,考虑如下两点 1、我不需要每一个服务都是单例类型 2、我不希望各个服务之间严重耦合,最好以接口来获取服务  

少用单例&降低耦合

单例是常用且最基本的一种设计模式。然而,单例的作用相当于全局对象,应避免过度使用 采用如下设计 针对每个Service类型,分别定义对应的IXxxService接口类型,不要担心类型爆炸(类型/接口 数量激增),Service毕竟不足10个   仅存在一个单例类型ServicesManager,其组合各Service实例,上层直接以ServicesManager.Instance.XxxService获取接口类型的服务对象     那么如何降低服务间的耦合呢,见下图   ServicesManger实现System.IServiceProvider接口,实现GetService方法,以作为服务提供者 组合一个集合类型用作容器,字典_serviceMap,key为Type,value为service实例 整体代码大致如下
    class ServicesManager : IServiceProvider
    {
        private static readonly ServicesManager INSTANCE = new ServicesManager();
 
        public static ServicesManager Instance
        {
            get { return INSTANCE; }
        }
 
        private readonly Dictionary<Type, object> _serviceMap = new Dictionary<Type, object>();
 
        public void AddService<T>(T service)
        {
            _serviceMap.Add(typeof(T), service);
        }
 
        public object GetService(Type serviceType)
        {
            return _serviceMap[serviceType];
        }
 
        public void Init()
        {
            UserCenterService userCenterService = new UserCenterService(this);
            userCenterService.Init();
            AddService<IUserCenterService>(userCenterService);
            // ...
        }
    }
  在Init方法中依次初始化各个Service对象,构造方法中注意传递this参数(将最为服务提供者),通过AddService泛型方法将各实例添加到容器中 每个Service均从抽象类型ServiceBase派生,基类ServiceBase维护一个IServiceProvider类型的字段_serviceProvider,引用实际的ServicesManager对象 ServiceBase的实现大致如下
    abstract class ServiceBase
    {
        private readonly IServiceProvider _serviceProvider;
 
        protected ServerServiceBase(IServiceProvider serviceProvider)
        {
            _serviceProvider = serviceProvider;
        }
 
        protected T GetService<T>() where T : class
        {
            return _serviceProvider.GetService(typeof(T)) as T;
        }
    }
  在各Service内部,可以使用方式如下获取其他Service实例
var realtimeDataService = GetService<IRealtimeDataService>();
realtimeDataService.xxxx

 

结语

这其实就是一个最基本的依赖注入实现,通过接口,各服务间得到了解耦。对于上层业务逻辑而言,也不需要知道各个Service的具体实现,甚至可以通过远程访问的方式,以接口的形式调用各种服务(实际上这个软件正是这样做的,一台机器维护数据,提供数据层Service接口,多客户端连接该机器查询数据,所有接口定义放在Common程序集中以供复用)   解耦合往往会加倍你的类型数量,提升复杂度。 开发中应该注意保持代码的简单易于维护,使其在任何时候都易于重构,做到这点你的软件就已经具备很强的生命力了。
上一篇: 雷军:去到别人连梦想都未曾抵达的地方 下一篇: 没有下一篇了!
发表评论
用户名: 匿名