2

我目前正在使用可恨的 Telerik Open Access，但也就是说，一般来说，使用 LINQ 和 ORM 没有架构问题吗？

我突然想到，我们正在做的是将数据操作的负担从经过优化以执行该任务的 DBMS 转移到在我的情况下不是的网络服务器。

此外，至少在 Telerik 的案例中，我们限制了编码模型的灵活性。在这个项目中，我必须提取并创建不直接映射到 CRUD 接口的复杂数据结构。至少在 Telerik Open Access 中，如果我使用存储过程来创建数据并且它没有映射到已知实体，我必须将数据作为对象数组返回。

因此，我使用 ORM 创建的“实体”并使用 LINQ 操作它们。与相对简单的等效 SQL 语句相比，生成的代码复杂得离谱。

我会对您关于使用 ORM 和 LINQ 的主张以及这在架构上是否不合理的观点感兴趣。

这对我来说当然是有感觉的。

我没有包含代码示例，因为实际代码无关紧要。也就是说，知道 10 行 T-SQL 查询（其中 6 行是连接）已经变成 300 行（包括空格）的 LINQ 语句来做同样的事情，这可能是有益的。

4

2 回答 2

3

如果您使用 Linq2SQL 或 Linq2Entities，它们实际上会生成 SQL 代码，并且“数据操作的负担”仍将在 DBMS 上。您编写的 Linq 代码在大小上将非常类似于 SQL 代码。

于 2012-08-20T10:51:42.967 回答
1

Using Linq in addition to an ORM isn't architecturally unsound.

You always have some amount of data manipulation on the database side and some amount on the client side. As a developer, it is yours to find the right balance. Obviously, if your ORM obliges you to do such convoluted things as manipulating a jumble of untyped data on the client side and doing massive queries on it with Linq, there's a problem. Either with your ORM or the way your system was designed.

于 2012-08-20T18:28:43.830 回答