设计模式建议 - 将 ViewModel 与域模型分开

Question

我需要将 MVC 项目中的 ViewModel 与位于单独库中的业务模型（数据访问层）分开。

假设我在单独的库中有数据库访问层类。我们的主要项目 (MVC) 对这些类一无所知，它们通过接口相互通信。使用 IOC 和使用 Ninject 解决依赖注入很容易，对吧？

现在 DataAccessLayer 包含名为 Car 的类，具有 Engine 和 Wheel 属性。在我的 MVC 项目中（它对 DataAccessLayer 及其类一无所知）我需要使用一些 Car 对象。所以我有另一个 Car 类（它只是一个纯 ViewModel），它具有相同的属性 - Engine 和 Wheel（当然在实际应用中，model 和 viewmodel 之间会有一些差异，为了简单起见我们忽略它）

IDataAccessLayer 接口有一个名为 IEnumerable GetAllCars() 的方法，它返回 DataAccessLayer.Car 对象的列表。 现在我需要创建 MVCProject.Car 集合，遍历 GetAllCars() 返回的 IEnumerable，在每次迭代中我需要创建一个新的 MVCProject.Car 对象，填充 Engine 和 Wheel 属性，最后将该对象添加到集合中。

所以：每次我必须创建几乎相同的结构并以某种方式在不同的地方管理它们。

这就是问题所在，明白了吗？或者不是？我觉得如果我不改变它，它最终会变得一团糟。不要重复自己违反原则的行为。请告诉我如何使它正确。使用我不知道的代理或原型或其他一些我很烂的设计模式。或者像 Ninject（我只知道如何将其用作 IOC 容器）或 Automapper 之类的工具，我可能会比设计模式更糟糕。

Answer 1

我也看不出将 DAL 与 MVC 层分开的理由。如果您有兴趣，这里是我用于多个项目的布局，我发现它非常实用且灵活。

数据对象 只有属性的基本对象。还包括 DataObjects 使用的枚举。

数据访问 继承DataObjects并添加GetByPrimaryKey、GetByForeignKey、GetByUniqueIndex、GetAll等。还包含缓存层，您可以在其中找到StateCache、CountryCache等，以便快速访问常用的东西。 “GetBy”方法将尽可能利用缓存层。

逻辑 静态类，每个 DataObject\Access 类型一个。包括除 DataAccess 层中详述的简单提取之外的逻辑工作。

网络\前端 UI 与 DataAccess 和 Logic 层一起使用以获取和更新对象以及调用其他已定义的逻辑 API。

我使用自己定制的代码生成器来生成 98% 的代码（UI 层除外）。

Answer 2

听起来您的 MVC 库应该了解您的数据访问库，不是吗？

或者，如果您真的想将 MVC 和 DAL 库分开，您总是可以添加第三个库，其中包含对 MVC 和 DAL 的引用。然后它可以处理从一个库中检索汽车，并将它们转换为另一个。

但是，我不明白为什么您的控制器（或 ViewModel，根据您的描述）不应访问 DAL。您的汽车 ViewModel 将从 DAL 检索 Cars 的实例，然后从那里开始。只要接收汽车的方式是通过接口编码的，您就应该能够稍后将其存根用于单元测试。

编辑

所以看起来您认为您稍后会更改整个 DAL，并且您希望将其难度降到最低？如果是这种情况，您可以查看adapter pattern。您会将所有 DAL 对象传递给适配器，适配器将返回给您业务层中的对象。然后，如果您的 DAL 发生变化，您只需更新您的适配器。

Answer 3

我找到了一种让它变得非常丑的方法:)

目标：调用者对DataAccessLayer的模型实体一无所知，通过接口获取所有数据。 如何在不手动映射 Model 和 Viewmodel 的情况下获取数据？ 通过反思。

 public IEnumerable<T> GetCars<T>()
    {
        var lst = new List<T>();

        _data.GetTable<Cars>().ToList().ForEach(x =>
        {
            var newCar = Activator.CreateInstance<T>();
            typeof(T).GetProperty("Engine").SetValue(newCar, x.Engine, null);
            typeof(T).GetProperty("Wheel").SetValue(newCar, x.Wheel, null);
            lst.Add(newCar);
        });

        return lst;
    }

它有效。但这里最大的问题是它是否公平且可观的架构决策？在现实生活中的应用程序中，性能将如何受到影响？