EF4 QueryView 还是 DefineingQuery?

发布于 2024-10-29 02:22:51 字数 513 浏览 0 评论 0原文

我正在尝试完成一个项目的设计,基本上已经走到了岔路口。我已经下定决心要使用 EF4 作为我的数据持久层,但是我现有的数据库给我带来了一些痛苦。更改或扩充数据库不是一个选项。我有一个表,它确实有多种用途,包含 120 列(这个表不是我设计的!!! - 它是很久以前 SQL Server 转换后的 DB2 结转)。我设计了一个类图,它从该表中以不同的聚合级别创建五个实体。在我对在这些情况下该怎么做的研究中,我将范围缩小到使用 MSL 层中的“QueryView”或 SSDL 层中的“DefiningQuery”来从这个整体表中创建我需要的实体。结果数据只需是只读的。我更喜欢返回一个适当的实体,但匿名类型或 dbdatarecord 也可以。

我尝试在 MSL 中使用 QueryView 以及在 CSDL 中定义的实体,但 MSL 不断重新生成,并且在编译时我的更改丢失。为什么?

任何人都可以提供关于我应该在这里做什么的意见吗?在这种情况下使用 DefiningQuery 或 QueryView 是否更好?在从数据库更新我的模型或编译后保留这些更改的任何输入也将非常感激。

I am in the middle of trying to complete a design for a project and have basically come to a fork in the road. I have made up my mind that I want to use EF4 as my data persistence layer, but my existing database is causing me some pains. Changing or augmenting the database is not an option. I have a single table that really serves multiple purposes and contains 120 columns (I didn't design this table!!! - it is a DB2 carryover after a SQL Server conversion long ago). I have designed a class diagram that creates five entities from this table, at varying levels of aggregation. In my research of what to do in these situations, I have narrowed it down to either using a “QueryView” in my MSL layer or a “DefiningQuery” in my SSDL layer to create the entities I need from this monolith table. The resultant data will only need to be read-only. I’d prefer getting back a proper entity, but anonymous types or dbdatarecord would be okay.

I have attempted to use a QueryView in MSL with my entity defined in my CSDL but the MSL keeps getting regenerated and my changes lost when I compile. Why?

Can anyone provide input as to what I should do here? Is using a DefiningQuery or QueryView preferable in this situation? Any input as to keeping these changes after updating my model from the database or compiling would be also very appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

节枝 2024-11-05 02:22:51

QueryView 不应重新生成。我不确定当您从数据库进行更新时 QueryView 的行为如何。我确信在从数据库更新时 DefiningQuery 将会被删除,因为 DefiningQuery 是在 SSDL 中定义的,在从数据库更新期间它被完全删除。我通过使用两种不同的 EDMX 为自定义 DefiningQueries 提供了一些解决方法 - 一种仅用于查询,第二种用于从数据库更新的实体。一般概念此处描述

QueryViewDefiningQuery 之间的区别在于包含这些构造的级别。 QueryView 是在现有实体之上构建为自定义 ESQL 查询的 MSL 元素,因此您的 120 列实体必须存在于 EDMX 中。由于未知原因 QueryView 不支持聚合。 DefiningQuery 是构建为自定义 SQL 查询的 SSDL 元素。它默认用于数据库视图(顺便说一句。可能是您的最佳选择)。

QueryView should not be regenerated. I'm not sure how QueryView behaves when you do update from database. I'm sure that DefiningQuery will be deleted when doing Update from database because DefiningQuery is defined in SSDL which is completely deleted during Update from database. I have some workaround for custom DefiningQueries by using two different EDMXs - one just for queries and second for entities updated from database. General concept is described here.

Difference between QueryView and DefiningQuery is the level where these constructs are included. QueryView is MSL element built as custom ESQL query on top of existing entity so your 120 columns entity must exists in EDMX. From unknown reason QueryView has no support for aggregations. DefiningQuery is SSDL element build as custom SQL query. It is by default used for database views (btw. probably best choice for you).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文