John Pappa Partials和BreezeJS在实体框架中使用直接支持，而不是在breezejs中进行预测

Question

遇到此问题： Collection navigation properties may NOT be set 我出于同样的原因

并在uservoice上发布此建议 https://breezejs.uservoice.com/forums/173093-breeze-feature-suggestions/suggestions/3796779-repository-sample-that-serves-view-models-

在看到伟大的新的紧凑元数据功能并查看edmunds示例后，我试图将它们放在一起，并提出一个解决方案，允许我从ef-codefirst web提供DTO的/ View模型与完整的域对象api后端，我想出了两个场景。

1）使用web api返回DTO /在JS中创建元数据并使用where参数根据需要进行过滤）因此据我所知，可以通过微风跟踪实体。这个问题是我必须覆盖保存更改并将dtos / viewmodels转换回EF域对象并保存它们。我不确定这是否像我能看到的那样简单/或复杂。基本上我提出的算法是将变换集中的根对象和相关子项作为DTO删除，然后将它们映射回Domain对象，然后将其添加到上下文并保存（看起来很多工作，我不完全确定必须完成的订单总是可知）

2）跟随Julie Lermans从Pluralsight Enterprise EF couurse领导并使用代码直接在EF中创建部分，然后让breeze按设计工作。 （在课程中，Julie创建了客户的精简模型，这些模型上有属性，告诉EF将其映射到客户表）

我很想听到任何人的想法。我个人倾向于＃2，但如果有可能使用工具从我的C＃clases中生成元数据，或者如果SaveChanges的实现可以被管理并且不会变成重写，我可能会被说服选择＃1 EF应该为我做的一半）

Answer 1

我自己也在研究相同的问题，最后我选择了2.对于我的情况，我觉得我对选项2有了更多的控制权，而且我能够更好地按照我想要的方式映射我的数据觉得我的层数比我个人项目所需要的多。 Julie Lermans“缩小与DDD有界背景的EF模型”（http://msdn.microsoft.com/en-us/magazine/jj883952.aspx）对我来说也是一篇非常有用的文章。