泛型 – 围绕WCF Web服务设计包装器以使用通用CRUD方法 – 一个很好的解决方案？

概述众所周知,使用泛型方法创建Web服务是不可能的.你必须设计信息. 但我有想法使用Reflection在WCF周围创建一个包装器. public class WcfRepository<T> : IWcfRepository<T> where T : class { public IList<T> GetList() { Typ 众所周知,使用泛型方法创建Web服务是不可能的.你必须设计信息.

但我有想法使用Reflection在WCF周围创建一个包装器.

public class WcfRepository<T> : IWcfRepository<T> where T : class     {        public IList<T> GetList()        {               Type wcfService = typeof (Service1ClIEnt);            string entityname = typeof(T).name;            string methodname = String.Format("Get{0}List",entityname);            object instance = Activator.CreateInstance(wcfService,true);            var result = (IList<T>) wcfService.InvokeMember(methodname,BindingFlags.InvokeMethod | BindingFlags.Default,null,instance,null);            return result;        }        public T Save(T entity)        {            throw new NotImplementedException();        }        public voID Update(T entity)        {            throw new NotImplementedException();        }        public voID Delete(int ID)        {            throw new NotImplementedException();        }    }

您可以像这样使用包装器：

var result = new WcfRepository<Employee>().GetList();

这是没有包装器的麻烦方式：

var customers = myWcfService.GetCustomerList();var teams = myWcfService.GetTeamList();var products = myWcfService.GetProductList();

那你觉得我的包装怎么样？
您可以看到哪些优点和缺点？

解决方法 您的实现的主要问题是WCF代理不便宜.反射不会对你造成太大的伤害,但是为每个请求创建一个新的代理(顺便说一句,没有正确地处理它)肯定会.

您的设计的主要问题是它假设每种类型的实体都支持相同的CRUD合同/接口.实际上,您可能有一些是只读的(引导程序和其他元数据),有些只是CR(日志或事务数据),有些只是CRU(关键的基础数据,如“商店”或“帐户”) “),有些根本不是真正的实体,需要额外的参数来检索.此外,您可能需要几种“GetByID / GetByXYZ”类型的方法,这些方法因类型而异;很少有消费者真正想要列出数据库中包含的每一个项目而没有任何过滤器或投影.

通过尝试创建通用抽象,您隐藏了关于服务实际可以支持的关键信息,并允许消费者做出他们不知道的假设是无效的,直到为时已晚.您已经创建了一个场景,允许代码以意外甚至不可预测的方式中断.

您的概念的主要问题是Web服务旨在封装业务或应用程序逻辑,而不是数据源.在DAL上创建薄单板不会给整体解决方案带来真正的价值,只是客户端将被迫处理的另一层间接. Web服务很棒,但是它们会增加大量的开发和维护开销,因为每个模式/数据更新都必须在两个地方而不是一个地方进行.将第3层(或第4层或第5层)添加到应用程序通常仅在该层提供一些额外的智能或至少封装时才适用.完全围绕数据访问 *** 作构建的服务架构是一种“糟糕的架构气味”,因为它们只是在功能严重受限的情况下重新实现数据库.

例如,针对“订单”的面向服务或消息的请求可能允许消费者指定任何或所有客户,日期范围以及一系列其他特定于域的标准 – 产品类型,数量,总成本,付款方式等.您可能希望将此全部合并到一个服务 *** 作中;消费者发送一条消息,详细说明他想要的内容,并相应地提供.当然,对“客户”的类似请求将不具备任何这些标准;相反,您可能会根据注册日期,地理位置,信用评级等返回结果.在这种意义上,每个请求都将是完全独特的;您正在向消费者提供服务,以使他们具有简单CRUD层很少提供的灵活性.您可以这样做,以便能够将其暴露给具有不同需求的各种不同的消费者,而无需不断更改服务的合同.您提出的架构并不适合这个最终目标.

这可能只是我的意见,而其他人可能还有其他事情要说;我可以补充的是,我将这些陈述建立在个人使用Web服务的经验基础上(我每天都在工作)而不一定是传统智慧 – 尽管我相信传统智慧在这里与我同意.

总结

以上是内存溢出为你收集整理的泛型 – 围绕WCF Web服务设计包装器以使用通用CRUD方法 – 一个很好的解决方案？全部内容，希望文章能够帮你解决泛型 – 围绕WCF Web服务设计包装器以使用通用CRUD方法 – 一个很好的解决方案？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。