Question

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

示例：我有一个User表。 EF创建用户实体。我有一个方法可能GetListOfUsers（）。在演示文稿中，不应该在列表上进行回复，因为用户界面会直接链接到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将项目放入Entity对象列表中，然后通过我的转换方法传递它们，使它们成为自定义的buily对象。转换采用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;
        }
    }

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

Answer 1

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

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

存储库模式的目的是：

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

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

Answer 2

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

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

考虑到转换层，我认为人们处理从一种类型到另一种类型的映射，当他们有一个简单模型（DTO）与数据库进行通信时，另一个域模型处理业务逻辑的所有细微之处，另一个one - 表示模型，最适合用户与之交互。这种分层将关注点分解为良好的衡量标准，使每个任务变得更简单，但总体上使应用程序更加复杂。因此，您可能会结束MyUserObjectDTO，MyUserObject和MyUserObjectView以及某些映射或转换。

实体框架业务对象转换

2 个答案: