实体框架设计-多个“视图”对于数据
我有一个与实体框架实体相关的设计问题。
我创建了以下实体：
public class SomeEntity {
// full review details here
}
作为示例，该实体有 30 列。当我需要创建一个新实体时，这非常有用。我拥有插入数据库所需的所有字段。
我的应用程序中有几个地方需要显示一些表格数据以及 SomeEntity 中的一些字段，但我不需要全部 30 列，可能只需要 2 或 3 列。
我是否创建一个全新的实体，它只包含我需要的字段（它映射到与 SomeEntity 相同的表，但只检索我想要的列？）
或者创建一个域类（如 PartialEntity）并编写更有意义像这样的查询：
var partialObjects = from e in db.SomeEntities
select new PartialEntity { Column1 = e.Column1, Column2 = e.Column2 };
我不确定做这种事情的适当方法是什么。让两个实体映射到同一个表/列是一个坏主意吗？我实际上永远不需要创建 PartialEntity 并将其保存到数据库的能力，因为它不会包含所需的所有字段。
I have a design question related to Entity Framework entities.
I have created the following entity:
public class SomeEntity {
// full review details here
}
This entity has as an example 30 columns. When I need to create a new entity this works great. I have all of the required fields in order to insert into the database.
I have a few places in my app where I need to display some tabular data with some of the fields from SomeEntity, but I don't need all 30 columns, maybe only 2 or 3 columns.
Do I create an entirely new entity that has only the fields I need (which maps to the same table as SomeEntity, but only retrieves the column I want?)
Or does it make more sense to create a domain class (like PartialEntity) and write a query like this:
var partialObjects = from e in db.SomeEntities
select new PartialEntity { Column1 = e.Column1, Column2 = e.Column2 };
I am not sure what the appropriate way to do this type of thing. Is it a bad idea to have two entities that map to the same table/columns? I would never actually need the ability to create a PartialEntity and save it to the database, because it wouldn't have all of the fields that are required.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
你的第一种方法是不可能的。 EF 不支持映射到同一个表的多个实体（除了一些特殊情况，如 TPH 继承或表拆分）。
第二种情况是常见的场景。您将为您的 UI 创建视图模型，并直接在查询中将您的实体投影到视图模型（它将仅从数据库传递您投影的列），或者您将查询整个实体并在应用程序代码中转换为视图模型（例如通过AutoMapper 正如@Fernando 提到的）。
如果您使用 EDMX 文件进行映射（我猜您没有这样做，因为您提到了 ef-code-first）您可以使用第三种方法，该方法来自上述两种方法。该方法定义了 QueryView - 它是映射实体上基于 EF 的视图，表现为新的只读实体。一般来说，它是直接存储在映射中的可重复使用的投影。
Your first approach is not possible. EF doesn't support multiple entities mapped to the same table (except some special cases like TPH inheritance or table splitting).
The second case is common scenario. You will create view model for your UI and either project your entity to view model directly in query (it will pass from DB only columns you project) or you will query whole entity and make conversion to view model in your application code (for example by AutoMapper as @Fernando mentioned).
If you are using EDMX file for mapping (I guess you don't because you mentioned ef-code-first) you can use third approach which takes part from both mentioned approaches. That approach defines QueryView - it is EF based view on the mapped entity which behaves as a new read only entity. Generally it is reusable projection stored directly in mapping.
您提出的第一个解决方案是“视图模型范例”，您创建一个类的唯一目的是作为视图的模型来检索数据，然后将其映射到模型类。您可以使用 AutoMapper 来映射值。这是一个 文章介绍如何应用此功能。
What you proposed as a first solution is the "View model paradigm", where you create a class for the sole purpose of being the model of a view to retrieve data and then map it to the model class. You can use AutoMapper to map the values. Here's an article on how to apply this.
您可以创建一个接受对象实例的通用属性过滤器方法，并传入一个列名称的字符串数组，该方法将返回一个仅包含所需列的动态对象。
You could create a generic property filter method that takes in an object instance, and you pass in a string array of column names, and this method would return a dynamic object with only the columns you want.
我认为添加基于相同数据结构的第二个实体会给您的模型增加不必要的复杂性。老实说，我没有看到使用单个实体进行更新\编辑\查看有什么问题。如果您坚持分离对 SomeEntity 的访问，您可以拥有一个数据库视图：即 SomeEntityView，并基于该视图创建一个单独的实体。。
I think it would add unnecessary complexity to your model to add a second entity based on the same data structure. I honestly don't see the problem in having a single entity for updating\editing\viewing. If you insist on separating the access to SomeEntity, you could have a database view: i.e. SomeEntityView, and create a separate entity based on that.