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

本邮件内容由第三方提供，如果您不想继续收到该邮件，可 点此退订 。

[原创]实例-少用单例及降低耦合 - Gods_巨蚁  阅读原文»

引言

我想就我个人开发时遇到的一些实际情况，与各位做一些分享，语言以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程序集中以供复用）

解耦合往往会加倍你的类型数量，提升复杂度。

开发中应该注意保持代码的简单易于维护，使其在任何时候都易于重构，做到这点你的软件就已经具备很强的生命力了。

本文链接：[原创]实例-少用单例及降低耦合，转载请注明。

Dynamic CRM 2013学习笔记（二十四）页面保存前进行逻辑验证 - 疯吻IT  阅读原文»

我们有时要验证下页面上的一些逻辑，比如开始时间不能晚于结束时间，不对时不让保存。我们可以在相关的字段事件上处理，但这如果要判断的字段比较多时，就比较麻烦了。 这时候我们就可以利用Form的OnSave事件，下面介绍下具体的做法：

1. Form的OnSave事件

2. JS方法

function formSave(context) { if (!dateCheck("new_valid_on", "new_valid_to")) { alert("Valid To is earlier than Valid On !") context.getEventArgs().preventDefault(); } if (!dateCheck("new_valid_from", "new_valid_to")) { alert("Valid To is earlier than Valid From !") context.getEventArgs().preventDefault(); } }

不符合条件时就用这句阻止保存：

context.getEventArgs().preventDefault();

是不是很简单，不用为每个相关的字段写一个方法了。

Dynamic CRM 2013学习笔记 系列汇总 -- 持续更新中

本文链接：Dynamic CRM 2013学习笔记（二十四）页面保存前进行逻辑验证，转载请注明。

阅读更多内容