业务逻辑层缓存应该设计

标签：des   style   blog   io   os   使用   ar   数据   问题   

        在业务制定的时候很少会切入缓存设计这一环节,毕竟在指标不明确的情况这属于一种过渡设计.毕竟缓存切入有很多手段,在很多时候直接在WEB进行一个页面缓存就有着非常高收益的效果.缓存是一种横向的数据处理应用,一般在设计中引入AOP,ICO的应用组件都可以在后期切入添加.但AOP,ICO在没有比较丰富的经验情况引入会直接增加应用的复杂度和风险.在设计主要介绍一种简单的设计方式在设计阶段引用缓存但又不带来复杂的工作成本.

一个简单示例

public class BlogService:Interfaces.IBlogService {
        public IList<Blog> List(string category, int size, int index, out int pages)
        {
            Expression exp = new Expression();
            if (!string.IsNullOrEmpty(category))
                exp &= Blog.iD == BlogLinkCategory.blog[BlogLinkCategory.category == category];
            int count = exp.Count<Blog>();
            pages = count / size;
            if (count % size > 0)
                pages++;

            return exp.List<Blog>(new Region(index, size), Blog.createTime.Desc);
        }

        public IList<BlogCategory> ListCategories()
        {
            return new Expression().List<BlogCategory>();
        }

        public Blog Get(string id)
        {
            return (Blog.iD == id).ListFirst<Blog>();
        }
}

        以上是一个完全不考虑缓存应用的情况,一般在前期都这样做,毕竟完成功能是首要面对的问题.

简单加入缓存

以List方法为例加入缓存处理方式.

public IList<Blog> List(string category, int size, int index, out int pages)
        {

            IList<Blog> result = redis.Get<IList<Blog>>("key");
            if (result == null)
            {
                Expression exp = new Expression();
                if (!string.IsNullOrEmpty(category))
                    exp &= Blog.iD == BlogLinkCategory.blog[BlogLinkCategory.category == category];
                int count = exp.Count<Blog>();
                pages = count / size;
                if (count % size > 0)
                    pages++;

                result = exp.List<Blog>(new Region(index, size), Blog.createTime.Desc);
                redis.Set("key", result);
            }
            return result;
        }

这一平时在开发中看到比较的方式,说实话一开始考虑这样做的确是增加比较大的工作量,特别在前期阶段没有性能要求的情况,这只会增长工作和延时进度.还有就是缓存产品的偶合性也强达不到比较好的秀明度;毕竟开发人员还要学习具体缓存产品的API.

缓存实现的解偶

         可以在设计的时候制定一个简单的缓存储访问接口.

public interface ICached
    {
        T Get<T>(string key);
        void Set(string key, object data);
    }

public interface IBlogService
    {
        IList<Blog> List(string category, int size, int index, out int pages);

        Blog Get(string id);

        Blog Save(string id, string title, string keywords, string data, params string[] categories);

        IList<BlogCategory> ListCategories();

        ICached Cached { get; set; }
   }

缓存规划应用简化

        其实在接口针对Get定义一些简单的委托参数可以简单Cache在应用时的复发度.

public interface ICached
    {
        T Get<T>(Func<T> handler, string key);
        void Set(string key, object data);
    }

{
        public IList<Blog> List(string category, int size, int index, out int pages)
        {
            dynamic eo = Cached.Get<dynamic>(() => {
                dynamic result = new ExpandoObject();
                Expression exp = new Expression();
                if (!string.IsNullOrEmpty(category))
                    exp &= Blog.iD == BlogLinkCategory.blog[BlogLinkCategory.category == category];
                int count = exp.Count<Blog>();
                result.Pages = count / size;
                if (count % size > 0)
                    result.Pages++;

                result.Blogs = exp.List<Blog>(new Region(index, size), Blog.createTime.Desc);
                return result;
            }, key);

            pages = eo.Pages;
            return eo.Blogs;
        }

        其实原理比较简单,就是Get内部实现如果相关key不存在的情况直接执行Func<T>的方法得到数据,并设置到缓存中.以上需要处理一些条件和分页返回所以感觉会复杂一些.一般代码下都简单.

public TextBlock GetByTitle(string title)
        {
            return Cached.Get<TextBlock>(() => (TextBlock.iD == title).ListFirst<TextBlock>(),title);

        }

总结 

        通过这样的设计在逻辑层或其他层面引用缓存设计并不会对整个代码带来多大的复杂度变化,刚开始完全可以引用一个完全都不做的ICached实现.在后期有需要的话直接更换代码.文章里的ICached的设计比较简陋毕竟只是用于体现这种设计模式而已.如果业务场复杂的情况这个ICached所反映的行为参数可能会复杂一些.不过开发人员总会有办法把复杂的调用变成简单的.

业务逻辑层缓存应该设计

标签：des   style   blog   io   os   使用   ar   数据   问题   

原文地址：http://my.oschina.net/ikende/blog/313353