sprocs(always) 是否应该返回完整的实体？

Question

我正在将 EF (4.2) 添加到现有的 .NET 项目中。

现有的代码库主要依靠ADO.NET调用多个sproc。现在我们正朝着 EF 迈进，我想确保我们以最好、最可维护的方式这样做。

我的问题是当前的 sproc 代码库并不总是返回以它们命名的实体的完整信息：

GetUsersByAdministrator(int adminId)

现有 (sproc) 代码仅返回用户 ID 以及名字和姓氏。

对我来说，这个函数不返回“用户”，并且不应该包含在用户业务逻辑中（如命名）。

对我来说，如果我们给人的印象是一个函数返回一个“用户”但没有返回完整的实体，这似乎很麻烦。

TL;DR

在实现 BLL 时，所有支持的存储过程都应该实现一个完整的实体吗？

例如是否总是需要用户类上的静态方法 GetUsersByXYZ 来返回完整的用户对象？

User.GetUsersByXYZ(int id)

这些函数是否应该更好地位于实用函数的单独程序集中，并将方法重命名为更合适的名称 Util.GetUserIdAndNamesByXYZ？

Answer 1

在实现 BLL 时，所有支持的存储过程都应该实现一个完整的实体吗？

没有。它们可以实现实体、复杂类型甚至未映射的类。

是否应该始终要求用户类上的静态方法（称为 GetUsersByXYZ）返回完整的用户对象？

那是关于命名的。您的存储过程当前返回的是用户数据的投影 - 它仅返回某些上下文中必需的数据。因此，让我们给投影另一个类型名称，例如 UserNameInfo 并使用它。

这些函数是否应该更好地位于一个单独的组件中？ 实用函数和方法被重命名为更合适的名称 Util.GetUserIdAndNamesByXYZ?

Helper 装配与否仍然取决于 EF => 它是数据访问的一部分。