实体、视图或内联 SQL
我正在研究将现有的 ASP.NET Web 表单项目转换为 MVC 2 Web 应用程序项目的可行性。现有的 SQL 查询的形式为：
Select [data]
from [table]
inner join [linkedDb1.Table] on key
where [constraints]
有两个链接的数据库。实体框架 4 不支持链接服务器。所以我必须选择：
A。为每个表创建视图并连接视图。
B。保留内联 SQL 并以某种方式编写自定义模型作为包装器，可供强类型 - 仪表板上的部分视图使用。
C。将每个数据库包装在 CRUD 服务中并连接到内存中（假设数据 < 100 行 x 10 列）。
A 看起来很简单，B 我不知道该怎么做，C 在架构上很干净，但可能会阻碍性能。
如何创建与 B 配合使用的自定义模型？是否有人预见到 A、B 或 C 会导致项目被扼杀？
I am researching the feasability of converting an existing asp.net web forms project to MVC 2 web apps project. The existing SQL queries are of form:
Select [data]
from [table]
inner join [linkedDb1.Table] on key
where [constraints]
There are two linked DB's. Entitity framework 4 does not support linked servers. So I must choose:
A. Create views for each table and join on the views.
B. Keep the inline SQL and somehow write a custom model as a wrapper that can be consumed by Strongly Typed - partial views on the Dashboard.
C. Wrap each DB in a CRUD service and join in memory (data is assumed < 100 rows by 10 columns).
A appears straight forward, B I don't know how to do, C is architecturally clean, but potentially performance hindered.
How do I create a custom model that works with B? Does anyone foresee any project killing ideas with A, B, or C?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
创建一个存储过程并将其添加到您的 dbml 中。它会更快并且会提供您正在寻找的 EF 对象。
Make a stored procedure and add that to your dbml. It will be faster and will provide the EF objects you're looking for.