我们开发了具有相当大的Db的后台应用程序。 将所有内容从DB加载到内存是不合理的，所以当请求模型的属性时，我们从DB读取（通过EF） 但是我们的许多UI只是简单的实体列表，其中有一些（！）属性呈现给用户。 例如，我们只想显示Id，Title和Name。 之后，当用户选择项目并想要执行某些操作时，需要整个对象。现在我们有存储在内存中的项目列表。 某些属性包含大型textst，图像或其他数据。 EF与实体一起工作并且读取一堆大对象会显着降低性能。
据我了解，可以通过创建轻量级实体并在适当的上下文中使用它们来解决问题。
首先。 我担心每个视图都会让我们创建新的LightweightEntity，最终我们会以膨胀的对象上下文结束。
二。当Model包装EF时，我们需要为各种实体提供方法。
第三。 ViewModels相互通信并传递实体。
所以我坚持所有这些考虑因素，需要良好的建筑设计建议。 有什么想法吗？
答案 0 :(得分：1)
对于大型文本的图像，您可以考虑使用table splitting，这通常用于在轻量级实体和“重”实体中拆分表。
但我认为你称之为轻量级“实体”的是数据传输对象（DTO）。这些不是由上下文提供的（因此它不会变得臃肿），而是来自实体的投影，这是在存储库或服务中完成的。
对于投影，您可以使用AutoMapper，尤其是我描述的here的新功能。这允许您减少“为各种实体”（DTO）提供所需的方法数量，因为要投影到的类型可以在泛型类型参数中给出。