4

我正在尝试创建一个使用 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;
        }
    }

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

4

2 回答 2

2

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

我同意业务流程应该独立于 UI。我也同意您的 UI 不应直接影响您访问数据的方式。您的建议（类似于“GetListOfUsers()”的内容）被称为存储库模式。

存储库模式的目的是：

将检索数据并将其映射到实体模型的逻辑与作用于模型的业务逻辑分开。业务逻辑应该与构成数据源层的数据类型无关

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

于 2012-08-18T20:11:50.693 回答
1

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

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

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

于 2012-08-18T20:15:41.923 回答