為什么我們不應該將業務邏輯放在服務中？ 我們會更換我們的服務嗎？

Question

我正在設計一個系統，我讀過很多文章說不要在你的服務代碼中加入業務邏輯。 並且只將您的業務邏輯放在域對象中。

我不是在任何地方托管我的服務代碼，而是由我的表示層直接訪問它。 將來，我可能希望通過WCF IIS服務公開此服務代碼。

但我不明白為什么服務應該輕量級？ 它的優點是什么？ 我們何時會更換我們的服務？ 請解釋

Answer 1

這個想法是通過在應用程序中使用不同的層，使其可重用。 例如，您的業務層可能具有簽出書籍的功能。 那么你可以使用該功能並從不同的層調用它。 控制台應用程序可以調用它，服務可以調用它，或者網頁可以調用它。

此外，它更容易測試。 您可以在只調用BLL的示例應用程序中觸發該方法，而不必擔心讓您的服務調用它。

Answer 2

根據我的理解，這是關於遵守單一責任原則的 。 一般的想法是，服務層的單一職責應該是將服務操作轉換為域操作。 也就是說，你編寫了一個服務類型，它公開了一個表示服務操作的方法，並將服務契約作為輸入。 服務方法將服務操作轉換為域操作，並讓域對象擔心業務規則。 這樣，您的類型將服務操作的轉換封裝到域操作，而不是其他任何內容。

請注意，我假設您所引用的文章中的“服務”代碼是指面向服務的體系結構中的服務接口。