我有一个问题已存在好几年了。众所周知，实体框架是一个ORM工具，它试图将数据库建模为面向对象的访问模型。我见过的所有样本都直接查询数据库表。那么，现在这个视图在数据库中的作用是什么？这些视图用于以更友好的方式对数据库建模，即几个物理表，一个逻辑表。这很好，例如隐藏存储过程的复杂关系模型，因为查询内部的视图比在每个存储过程上一遍又一遍地重现查询连接要容易得多。所以问题是，如果存储过程不能从中获益，为什么实体框架如此好？？
我将尝试以另一种方式解释同样的事情。你有一个名为category的表。你有另一个名为elements的表。每个元素可以有几个类别，一个类别可以包含多个元素。对于每个类别，我想计算有多少元素（这很简单，但想象这个计算有一个非常复杂的公式）。现在出现了问题：
选择1：使用此计算创建视图VCategory。 选择2：在实体框架中包含表类别，然后扩展类以包括计算。
优点选择1：计算可供所有人使用。 对比选择1：视图不可更新。
优先选择2：该表是可更新的 对比选择2：计算仅适用于.NET兼容系统。
选择一个1：如何使用实体框架处理此更新？导入视图并映射插入，更新，删除存储过程？。
选择一个2：存储的程序无法从实体框架中受益。如果数据库上的一个存储过程需要进行此计算，该怎么办？
答案 0 :(得分：1)
不明白你的意思......
实际上，如果它们可以更新，你可以大量使用你的观点...那么使用orm +程序怎么样？ 您仍然可以在实体框架中使用数据库视图，并以“更友好的方式”获得模型。