实体框架业务对象转换答案

【问题标题】：Entity Framework business object transformation实体框架业务对象转换
【发布时间】：2012-08-14 20:17:45
【问题描述】：

我正在尝试创建一个使用 EF 处理数据访问的小型个人项目。我的项目架构有 UI 层、服务层、业务层和数据访问层。 EF 包含在 DAL 中。我认为从我的 UI 中引用我的 DAL 是不对的。所以我想为我的所有层之间共享的“业务对象”创建自定义类。

示例：我有一个用户表。 EF 创建一个用户实体。我有一个方法可能是 GetListOfUsers()。在演示文稿中，不应回复列表，因为 UI 会直接链接到 DAL。我可能需要在 DAL 中公开一个方法，可能类似于：

List<MyUserObject> GetListOfUsers();

然后调用我的内部方法 GetListOfUsers 返回用户实体列表，然后将它们转换为我的 MyUserObejcts，然后通过层传递回我的 UI。

这是正确的设计吗？我不认为 UI 或业务层应该对实体框架有任何了解。

不过，这可能意味着我可能需要在 DAL 和业务层之间建立一个“转换层”，将我的实体转换为我的自定义对象？

编辑：

这是我正在做的一个例子：

我有一个数据访问项目，其中将包含实体框架。在这个项目中，我将有一个方法来获取状态列表。

public class DataAccessor
{
    taskerEntities te = new taskerEntities();

    public List<StateObject> GetStates()
    {
        var transformer = new Transformer();
        var items =   (from s in te.r_state select s).ToList();
        var states = new List<StateObject>();
        foreach (var rState in items)
        {
            var s = transformer.State(rState);
            states.Add(s);
        }
        return states;
    }

}

我的 UI/业务/服务项目一定不知道实体框架对象。相反，它必须知道我自定义构建的 State 对象。所以，我有一个共享库项目，其中包含我的自定义构建对象：

namespace SharedLib
{

    public class StateObject
    {
        public int stateId { get; set; }
        public string description { get; set; }
        public Boolean isDefault { get; set; }
    }


}

所以，我的 DAL 将项目放入实体对象列表中，然后我将它们传递给我的转换方法，以使它们成为自定义的构建对象。转换接受一个 EF 对象，并输出一个自定义对象。

public  class Transformer
    {
        public StateObject State (r_state state)
        {
            var s = new StateObject
                        {
                            description = state.description, 
                            isDefault = state.is_default, 
                            stateId = state.state_id
                        };

            return s;
        }
    }

这似乎有效。但这是一个有效的模式吗？

【问题讨论】：

标签： c# entity-framework

【解决方案1】：

因此，在某些时候，您的 UI 将不得不使用您拥有的数据和业务对象。这是生活中的事实。您可以尝试进一步抽象，但这只会成功地将交互推迟到其他地方。

我同意业务流程应该独立于 UI。我也同意您的 UI 不应直接影响您访问数据的方式。你有什么建议（类似于“GetListOfUsers()”）被称为Repository Pattern。

存储库模式的目的是：

分离检索数据的逻辑并将其映射到实体模型来自作用于模型的业务逻辑。这生意逻辑应该与包含数据的数据类型无关源层

我的建议是使用存储库模式来隐藏您访问数据的方式（并允许更好地分离关注点）并且只关心您“只想要用户列表”或您“只是想计算所有时间表的总和”或您希望应用程序实际关注的任何内容。阅读链接以获得更详细的说明。

【讨论】：

谢谢！我不知道模式（可能应该阅读那个四人帮？？）。我更详细地更新了我的问题，但看起来我确实在你所说的轨道上。现在看起来有效吗？

【解决方案2】：

首先，您真的需要在您的“小型个人项目”中使用所有层吗？其次，我认为您建议的架构有点不清楚。

如果我猜对了，您希望将您的 UI 与您的 DAL 分离。为此，您可以例如提取MyUserObject 的接口（显然在DAL 中定义）类，我们称之为IMyUserObject，而不是从UI 中引用DAL，而是引用一些抽象项目，其中所有类型都是数据不可知的.另外，我建议您拥有一些服务层，为您的表示层 (UI) 提供具体对象。如果你使用 MVC，你可以从你的控制器类中获得服务的链接。服务层反过来可以使用 Repository 或其他一些技术来处理 DAL（这取决于您选择的复杂性）

考虑到转换层，我认为人们处理从一种类型到另一种类型的映射时，他们有一个简单模型 (DTO) 与 DB 通信，另一个 - 域模型，处理业务逻辑的所有微妙之处，还有另一个one - 展示模型，最适合让用户与之交互。这种分层将关注点分开，使每个任务更简单，但总体上使应用程序更复杂。因此，您可能最终拥有 MyUserObjectDTO、MyUserObject 和 MyUserObjectView 以及一些映射或转换。

【讨论】：