簡單 C# 控制台應用程序中的良好架構

Question

我正在開發一個簡單的 git 存儲庫，其中包含一些 C# 控制台應用程序項目，這些項目通常在我開始使用 .NET 開發以來經歷的工作面試中被要求。

我的問題是我在使用良好的架構實踐時遇到了一些麻煩。 多虧了這一點，我總是花費數小時試圖在我的解決方案中描繪出最好的文件夾和文件位置。

例如：

這是該回購的結構。

我在這個 job-interview-tests 存儲庫中的第一個項目是一個檢查素數的控制台應用程序，在實現邏輯之后我注意到我想創建一些 class 來處理控制台文本（例如： Console.WriteLine() ) 用於標題、錯誤和其他內容。

這是我的 PrimeNumber 文件夾的 Program.cs 文件。

using System;

namespace PrimeNumber
{
    class Program
    {
        static void Main(string[] args)
        {            
            try
            {
                Console.WriteLine("\nBem-vindo ao código de Testagem de Números Primos!");
                Console.WriteLine("--------------------------------------------------");
    
                Console.Write("\nInsira um número inteiro natural: ");
                var number = Convert.ToUInt32(Console.ReadLine());

                var result = CheckPrimeNumber(number) ? $"{number} é um número primo" : $"{number} não é um número primo";

                Console.WriteLine("\n" + result);
            }
            catch (FormatException)
            {
                Console.WriteLine("Opa! O valor inserido não é válido");
                //throw;
            }
            catch(OverflowException)
            {
                Console.WriteLine("Opa! Você inseriu um número negativo ou um número muito grande");
                //throw;
            }
            catch(Exception)
            {
                throw;
            }
        }

        public static bool CheckPrimeNumber (uint number)
        {
            bool isZeroOrOne = false, isPrime = false;

            switch (number)
            {
                case 0: 
                case 1:
                    isZeroOrOne = true;
                    isPrime = false; 
                    break;
            }    
                
            if (!isZeroOrOne)
            {
                for (int i = 2; i < number; i++)
                {                
                    if(number % i == 0)
                    {
                        isPrime = false;
                        break;
                    }
                }
            }

            return isPrime;
        }
    }
}

由於后續的控制台應用程序項目也將使用Console.WriteLine()命令與用戶進行通信，因此我想創建一個 class 來適應TextTools.Title(titleName) 、 TextTools.Error(errorMessage)和很快。

這個 class 會被放置在不同的文件夾中（例如：TextTools）嗎？ 會是 static class 嗎？ 或者也許是一個抽象的？ 我不確定什么是最好的方法。

我真的很想對這些疑問有所了解，這樣我就可以開始在我自己的小項目上取得進展，所以如果您能留下任何建議，請提前感謝您！

Answer 1

我的部分答案來自《 自適應代碼》，第 2 版

Visual Studio IDE 將允許您創建一個解決方案，即一組項目。 項目可以是任何類型的：控制台、庫、winform 或 WPF 等...

您的項目應該遵循N-Tiers模式，其中層代表應用程序的一部分（這里是由項目表示的上下文）。 一個層可以是你的

• Presentation Layer （控制台類型，winforms 等...）
• Business Logic Layer （用於業務規則 -> class 庫類型）
• Data Access Layer （訪問您的數據庫 -> class 庫類型）
• Business Object Layer （代表您的業務模型 -> class 庫類型）甚至一個
• Utility classes Layer ，如您的情況（-> class 庫類型）。

例如，您應該避免static類並將您的類放在實用程序 class 庫中。

在Visual Studio中，您的項目將如下所示，您可以通過單擊Solution > Add > New Project ：

Answer 2

如果您將有幾個項目，那么創建一個包裝控制台的專用項目而不是從您的其他項目中引用它是一個好主意。

如果您使用的是 .net 核心，更好的方法是使用 ILogger [https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-6.0][1]

Answer 3

對於良好的托管，我幾乎總是會考慮以下幾點：

• 嘗試將應用程序與主機分開
• 嘗試將接口與程序和主機分開
• 盡量減少加載所需的 dll 數量
• 嘗試減少庫中的依賴

因此，在您的情況下，程序托管在控制台應用程序中，僅使用 program.cs class 以確保正確讀取您的環境並設置任何 DI 內容，然后啟動主應用程序並在單獨的應用程序中執行主應用程序class，見上面的第一個引腳。

然后因為您可能還想在單元測試中托管您的程序，也許作為服務或 WPF、Web 或其他什么不。 不僅將您的主應用程序放在 class 中，而且將 class 放在庫中，因此您的主機只需處理為啟動應用程序提供/注入所需的內容。

考慮您的應用程序的某些部分是否會被不同的實體使用。 一個很好的例子是提交者和消費者都可以從服務總線使用 DTO（數據傳輸對象），例如，如果將您的應用程序放在另一個庫/dll 中，而不是您的應用程序，以便不引用從其他地方共享的內容，通常依賴項也會經常在不需要的地方傳播垃圾。

你有 DAL 嗎？ （數據訪問層）的含義是在例如 EF（實體框架）或 BSON 中是否需要屬性注釋或使用，或者您在接口部分中確實不需要的東西也使用了其他地方（參考問題之前提到過，還暴露您的數據訪問方法至少不會增加安全性）如果是這樣，請計划與 DTO DAL/BLE 之間的轉換

您需要 BLE 層嗎？ （業務層實體）意味着除了您如何存儲和檢索數據以及以何種方式通過網絡發送數據之外，是否值得權衡 model 特定的 class 對象系統，更多 Z20F35E630DAF44DBFA4C3F68FZ539 業務人員認為他們在做什么讓model和開發過程中的事情更容易講。 例如 OrderManager ......詢問用戶案例我的訂單經理應該能夠做什么，添加新訂單，查詢現有訂單，通過什么......等等。如果可以想象你的訂單會有明顯不同的事情數據甚至使用非共享 dto 結構，請考慮將您的 BL 與 DTO 和 DAL 分開。

在您的問題區域非常有限並且您處於面試情況的情況下，我建議您通過為每個庫創建一個文件夾並適當地放置您擁有的內容，在您的單個庫程序集中暗示這些想法。

實際上，在有用例之前不要進行物理拆分總是一個好主意，為了不必加載多個程序集，如果更少就足夠了，經驗法則是第一次從更多地方需要它這可能是物理分離的好時機。

如果可以，請始終使用 .net 標准作為共享庫。 在您的程序拓撲中使用 .net 框架應用程序時，將其保持在最多 .net 標准 2.0

我想這總結了我的通用架構建議，希望它們能為您節省一些頭痛，而不必在發生原因時解決它們背后的原因：)