小编Gre*_*gJF的帖子

我有一个gulp文件,里面有2个任务1.从目录中删除*.html文件2.将*.html文件复制到一个目录

我有Visual Studio 2017的Task Runner Explorer设置,以便:

• 在构建之前运行任务1
• 构建后运行任务2

如果我从Visual Studio 2017的Task Runner Explorer运行任务,它们就可以工作

当我执行Visual Studio 2017的发布时,任务运行器资源管理器事件不会触发.我们怎样才能让他们在Publish上解雇？

自从它首次问世以来,我一直在使用EF.用于在3.5中手动构建POCO,很高兴看到EF4.0中的自跟踪实体(STE).

我在一些非常大的项目中使用了STE(500多个实体,一些有多个模型).在这些项目中,我使用通用存储库和通用工作单元来持久化实体,即2个小类通用类没有映射.通过选择核心实体作为"聚合根",在客户端添加和更新其他实体,并将包含这些更改的核心实体图发送到WCF服务并在创建存储库<[核心实体]的逻辑层中使用]>并使用UnitOfWork <[核心实体]>.保存(存储库<[核心实体]>)以将STE及其子节点持久保存到数据库中.

现在微软建议我们不要使用STE.看到这篇文章

所以我的问题是,对于那些将客户端更改持久保存到使用EF的WCF服务的应用程序,Microsoft现在推荐的模式是什么？

我创建了一个EF5模型并检查了生成的代码.WCF服务没有属性,即DataContract,DataMember等

EF4有一个"支持WCF的ADO.NET DbContext生成器"模板,但没有EF5等价物.

一个站点建议我应该使用部分类文件并使用这些属性修饰该文件中的相同属性.但除非.net 4.5引入了部分属性,否则我无法看到如何做到这一点.

另 一篇博客 建议使用DTO和Automapper,这意味着更多的映射容易出错; 特别是当实体字段改变类型时.

所以现在DBContext生成的代码类没有启用Service,这是否意味着我们需要编写另一组类(POCO):

• 在查询数据库之后,需要从DBContext生成的代码类映射.
• 保存WCF服务客户端的数据状态
• 可由客户端更新
• 由客户映射
• 能够保持更改状态,以便将其发送回WCF服务
• 需要映射到DBContext生成的代码类以实现持久性

看起来我们刚刚向EF3迈进了一大步.

如果您对在硬件上运行的客户端和服务进行编码,则无需担心客户端属于您的数据结构.

如果您还需要向非.NET客户端公开一些服务方法,那么无论如何都应该为这些服务执行上述5点,并在这些场合使用DTO和Automapper.这些应该在不同的WCF服务中,但是针对相同的逻辑实现图层映射后.

但是,在大多数软件团队的Web应用程序的日常构建中,有多少这类非.NET客户端服务被创建？

这个最新的建议令人困惑,因为它没有被解释为什么STE总是构思错误,现在是什么,建议的模式用于持久化客户端更改使用EF的WCF服务.

任何人都可以告诉我哪里可以找到解决这个架构设计问题的好资源？

PS

请不要推荐WCF数据服务或WCF RIA,因为我们需要对客户端检索和保存数据的方式进行大量控制.

请不要推荐Code First,因为我们使用Database First,因为我们希望拥有并且需要控制该数据库的结构而不必为我们生成.