什么是適合我的案例的基於 MVC 的 OOP 設計？

Question

假設以下基線設計：我有一個CarElement類，它包含與汽車的視覺表示和數據模型/邏輯表示相關的屬性和方法：

class carElement
{

    // UI related properties and methods:
    public Size DrawSize { get; set; }
    public Point Location { get; set; }

    public void Draw()
    {
        // do something...
    }

    // data model / logic related properties and methods:
    public double weight { get; set; }
    public string manufacturer { get; set; }

    public double CalculatePrice()
    {
        // do something...
        return 0;
    }
}

這個類的用法如下： carElement多個實例被繪制到某個畫布上。 單擊每個繪制的汽車會使用propertygrid.SelectedObject = InstanceOfcarElement在屬性網格中顯示該汽車的屬性。

在我看來，這種設計是有缺陷的，因為數據模型和可視化表示在類設計中沒有分開。 我想改進面向 MVC 的設計，我正在尋求有關良好設計決策的建議。

我目前對此的carElement是將上面的carElement類分成以下兩個類。

class carUIElement // organizes visual representation of a car
{
    public Size DrawSize { get; set; }
    public Point Location { get; set; }

    private carDataElement linkedCarDataElement;

    public void Draw()
    {
        // do something...
    }

}

class carDataElement // organizes data model organization of a car
{   

    public double weight { get; set; }
    public string manufacturer { get; set; }

    private carUIElement linkedCarUIElement;

    public double CalculatePrice()
    {
        // do something...
        return 0;
    }
}

使用這種方法，我不清楚以下幾點：

• carUIElement應該知道它鏈接到的carDataElement ，反之亦然。 有沒有比上面代碼中的簡單鏈接更好的設計方法？
• 單擊繪制的 UIElement 時，如何最好地在屬性 Grid 上同時顯示 UI 和數據模型屬性？

整體方法是否可行？ 以上開放點呢？ 我錯過了判斷這一點的經驗，所以我會很感激你的評論。 謝謝你。

Answer 1

好吧，雖然我們應該始終小心不要過度智能化，畢竟我們作為程序員比藝術家更像是泥瓦匠，即使聖母教堂只是一個建築而不是藝術，也不總是需要過高的裝飾和隔音室，假設下一個版本會和上一個一樣盛大:)

我是什么意思？ 我建議 MVC 實用主義，所以如果在程序的早期階段，它可以有 ui 模型，有時也稱為數據傳輸對象，與邏輯模型相同，這本身不是反模式 imo。 顯然，一旦構建了 ui，我們就開始發布具有假定構造的實例，當它開始限制產品的開發時，它是如何呈現的，通常是當您需要更多與 ui 相關的信息時，存儲在實體中，然后您可以通過創建 DTO 模型對象並使用初始模型來鎖定接口。 所以我知道你要去哪里以及為什么你可能想要將它分開。

再說一次，我們經常有 Web 前端，尤其是使用 mvc，然后大多數情況下它將不再是數據綁定視圖，而是像 Angular、React、Vue 甚至 Blazor 之類的 MVVM 之類的東西，如果出於某種原因你可能想要它，或者傳統的 Razor頁，真的嗎？ 在新的發展？？ 如果只有序列化的 JSON 版本可用於您的視圖引擎，我盡量不將任何內容放入 DTO 類中。 因此，當現代化發生時，您的控制器/api 不必主要更改。

因此，單獨的單獨類與數據訪問或傳輸類中的邏輯無關，我的建議將是以下幾行，但最終會提出您的問題：

a) 如果您使用它來加載數據模型中的導航屬性，例如使用實體框架，則它是必需的。 在您的 UI 類型中，頻率是關鍵，通常我們喜歡將所有數據推送到點中，這樣它們就不需要執行任何其他操作，但是如果類正在被序列化和反序列化並且您使用 AutoMapper 之類的工具移動到從，如果您在像 WPF 這樣的 Windows 客戶端中，嘿您的模型已經在客戶端上並且已經為 MVVM 加載，那么您處於一個更好的位置，您可能不會誠實地關心前端類型，直到他們需要改變。

b) 問題是你是否總是想同時顯示這兩個元素，或者你可以隱藏 cardata 元素直到他們要求它，這將決定讓 DTO 包含來自關系的數據或只包含外鍵的選擇，並有一個額外的可用的查找方法imo。

所以建議簡短：

/// <summary>
/// Drawing is a separate concern of the application
/// </summary>
class DrawManager
{
    public void DrawCar(CarBase car) { }
}

/// <summary>
/// So is calculating prices
/// </summary>
class PriceManager
{
    decimal CalculateCarPrice(CarBase car) { throw new NotImplementedException(); }
}

/// <summary>
/// The 2 classes share properties, invent a base class to abide by the DRY principle
/// </summary>
class CarBase
{
    public Size DrawSize { get; set; }
    public Point Location { get; set; }
}

/// <summary>
/// Now they are identical
/// </summary>
class carElement : CarBase
{
    carDataElement CarData { get; set; }
}

/// <summary>
/// Now they are identical
/// </summary>
class carUIElement : CarBase
{
    carDataElement linkedCarDataElement;
}

/// <summary>
/// The data about a car, in RDBMS typically normalized into a seperate entity like you have,
/// does UI really need any of them? Is it always needed when other members are accessed? 
/// </summary>
/// <remarks>
/// we could choose to have the data model have a navigation property and then let the ui member not have it and give it a method to ackquire it,
/// but then that shouldn't get done to early and well if it always needs it, it is not yet a seperate datatype justification for the ui aspect
/// </remarks>
class carDataElement
{
    public double weight { get; set; }
    public string manufacturer { get; set; }
}