我一直在寫這是應用分層爲：層設計中的應用
DB < - > DAL < - > BL < - >服務< - >演示
而這是獲得真實引用的所有。即演示文稿沒有對DAL的引用。
我們爲客戶寫了一個新應用程序，客戶正在提出一些對我來說是陌生的東西。也就是說，WRITE流程通過SL，但是從數據庫讀取數據，我們希望在演示文稿中有一個linq查詢，直接指向DAL。這看起來很奇怪，但我被告知我的方式是老式的，我的方式和他們提出的方式本質上是一樣的。另外，我的業務邏輯通常駐留在BL中，這是一個單獨的項目。但客戶希望業務邏輯在DTO對象本身中。
這是正常的嗎？這基本上是域驅動開發還是什麼？我覺得奇怪的是，LINQ調用來獲得數據的形式，是在表示層，而不是我一個服務層方法的想法：
public MyPersonObject GetPersonByPersonId(int personId)
然後在業務，同樣的方法，可能會將某些規則應用於獲得的內容，然後在具有Linq的DAL中使用相同的方法。
客戶端是客戶端，你有沒有聽說過CQRS？
您的客戶可能會受到CQRS的影響，CQRS是領域驅動設計中的一種新架構時尚。一般來說，它以不同的方式將命令和查詢分離到數據庫。
但是在您的客戶提出的方法中，傳統的DDD和CQRS之間似乎混雜在一起，它不使用event sourcing。但它仍然正常，恕我直言，爲表示層提供數據的查詢是微不足道的，它並不複雜。這就像是從數據庫查詢數據的報告系統，您不需要使用ORM。
此外，我的業務邏輯通常駐留在BL，這是一個單獨的項目。但客戶希望業務邏輯在DTO對象本身中。
業務邏輯應該在域實體中，如果沒有，似乎你違反了Anemic Model anti pattern，它也不在DTO中。 DTO是分佈層與消費者之間數據傳輸對象的概念。
你所描述的不是DDD。儘管一些DDD實現在查詢和命令（CQRS方法）中使用拆分體系結構，但它並沒有消除對應用程序良好分層的需求。
如果寫入經過一個服務層，這可能意味着你的軟件至少是合理的複雜性，因此，應脫鉤的持久性表現在之間的抽象層。在CQRS中，該層通常採用Facades的形式接受查詢並返回包含所需數據的DTO。
但客戶希望業務邏輯自己在DTO對象的 中。
DTO代表數據傳輸對象。 DTO不包含任何業務邏輯，除了攜帶數據外沒有其他用途。