Question

我目前想知道从应用程序逻辑部分（服务器端）分离普通模型类（例如在Entity Framework，Web API，MVC，WCF中使用它们）的建议方法是什么？使用DRY原则的任务，线程等。

考虑这个pseduo示例：

public class HorseOfDoom {

    private Thread _hungerThread;
    private Laser  _headMountedLaser = new Laser();

    public int Age { get; set; }
    public string Name { get; set; }
    public int Health { get; set; }
    public int HungerLevel { get; set; }

    public HorseOfDoom() {
          _hungerThread.Start();
    }

    public void PewPew() {
        _headMountedLaser.PewPew();
    }

}

在这个类中，我们有两个 - 描述模型的模型属性（年龄，名称，...），还有一个线程和方法。我可以在Entity Framework，WCF等中使用这个类..但是如果我想在ASP.NET MVC客户端应用程序中使用该模型而不暴露方法，线程呢？我是否必须再次写同一个班级？我需要经理，适配器和外墙吗？我可以使用好友类模式吗？

Answer 1

使用适合上下文的模型。 DRY不是重复代码行，而是重复行为。您的视图模型可以具有与业务模型相同的属性（复制粘贴ftw），减去方法。您可以使用Automapper将一个映射到另一个。有可能您的视图模型将不仅仅包含那些属性，包括验证属性或视图所需的其他数据。

从长远来看，统治一切的模式并不好。清洁模型将使您更好地关注上下文并避免耦合到其他上下文，这些上下文可能使用非常相似或相同的模型。事情随着时间的推移而变化，从一开始就使用特定的模型更容易，即使这涉及到复制粘贴，似乎你在重复自己。

Answer 2

我理解你在样本中展示它的组合并不是理想的 - 我的主要观点批评将是一个已经暗示对象应该如何行为的非常具体的方式。类本身中包含的线程在某些环境中使用该类会更加困难的可能性很高。从我的角度来看，集成类的平台应该能够选择如何编排类的动作 - 当然，类可以做出一些限制，例如“不要在单独的线程中使用，因为类没有实现以线程安全的方式“。
至于是否在一个类中组合属性和方法：我不认为有一个明确且始终有效的答案。这在很大程度上取决于应用程序的体系结构有多大，以及您是否愿意在复杂性和开销方面为分离付出代价。
在单个类中组合属性和方法的概念通常称为 "Domain Model" 。这是设计复杂业务逻辑的一种非常自然的方法。
如果您拥有一个可以很好地分离各个层的体系结构，那么您将在业务逻辑中拥有一个实现业务规则的域模型。这些类组合了属性和方法，但这些类映射到只将数据传输到其他层的更简单版本（例如DTO）。这样，您还可以从域模型中分离服务接口，并在对其他层的影响最小的情况下更改它们。例如，如果域模型中有复杂的类，并且您希望在Web界面或服务层中仅显示此信息的一部分，则可以创建一个或多个DTO类，其中包含所需的数据。域模型的更改不一定会影响客户，因此您可以在这方面获得自由 在较小的架构中，如果可以忍受后果，则可能不需要将层与DTO分开。
至于上面提到的 WCF 示例，您通常会在不同的类中实现单独的服务和数据协定。如果在作为数据协定的类中有其他方法，则这些方法不会成为数据协定的一部分。您必须明确地制作要发布服务合同一部分的方法。如果您不与服务客户端共享类（例如通过类库），客户端甚至不会知道这些方法存在。

适当的模型和上下文类分离（架构）

2 个答案: