我正在将EF（4.2）添加到现有的.NET项目中。
现有的代码库主要依靠ADO.NET来调用多个sprocs。现在我们正在向EF迈进，我想确保以最好，最可维护的方式这样做。
我的问题是当前的sproc代码库并不总是返回它们命名的实体的完整信息：
GetUsersByAdministrator（int adminId）
现有（sproc）代码仅返回userId以及名字和姓氏。
对我来说，此功能不会返回“用户”，也不应包含在用户业务逻辑中（如命名）。
对我而言，如果我们给人的印象是函数返回“用户”但不返回完整的实体，那么这似乎很麻烦。
TL; DR
实现BLL时，是否所有后备存储过程都实现了一个完整的实体？
e.g。应该是一个名为GetUsersByXYZ的Users类的静态方法是否总是需要返回一个完整的User对象？
User.GetUsersByXYZ（int id）
这些函数是否应该更好地位于实用函数的单独程序集中，并且方法可以重命名为更合适的名称Util.GetUserIdAndNamesByXYZ？
答案 0 :(得分：1)
实现BLL时，是否所有后备存储过程都实现了一个完整的实体？
没有。它们可以实现实体，复杂类型甚至未映射的类。
如果一个名为GetUsersByXYZ的Users类的静态方法总是需要返回一个完整的User对象吗？
这是关于命名。您的存储过程当前返回的是用户数据的投影 - 它仅返回某些上下文中所需的数据。因此，让我们为投影提供另一个类型名称，例如UserNameInfo并使用它。
这些功能应该更好地位于单独的组件中 实用程序函数和方法被重命名为更合适的名称 Util.GetUserIdAndNamesByXYZ？
Helper assemlby与否它仍将依赖于EF =＆gt;它是数据访问的一部分。