在大多數CRUD應用程序中繞過業務層可以嗎？

Question

我正在研究一個應用程序，其中絕大多數功能是數據庫表和視圖之間的一對一映射。這是一個純粹的CRUD應用程序。

但是，有一些涉及一些業務規則的情況。例如，如果用戶正在創建「受限測試」，則需要輸入公司信息，但如果它不是「受限測試」，則公司信息是可選的。

在這些情況下，視圖是否可以直接使用沒有中間業務對象的數據庫對象，並僅針對涉及業務規則的情況實現業務對象？

作爲一個側面的問題，我使用了一個ORM框架，它不允許我在實體字段上實現getter/setter代碼。因此，這些實體對象上的所有字段基本上都是公共的，並且可以隨意更改。這是否足以爲每個實體類創建一個「業務對象」來保護像PK這樣的不變量？

編輯：

我發現馬克塞曼一個非常有用的職位，這似乎回答一半我的問題非常好。 http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/

Answer 1

是的，沒關係繞過垃圾服務。沒問題，但......你確定在6個月內它仍然是一個殘破的東西嗎？你能預見新的業務需求嗎？因爲如果有新的邏輯出現，它會慢慢來，一個接一個要求。你會注意到你必須重寫分層的那一刻嗎？你能否說服企業，你需要時間和金錢來支付這一變化？和其他開發人員花時間重寫代碼？

所以從設計的角度來看：是的，它完全沒問題。但在現實生活中，它可能是危險的

Answer 2

理想情況下，您應該使用業務層，特別是在使用ORM時。當您使用ORM時，實體正在相互引用。

你永遠不知道什麼時候傳入的業務對象需要拆分，合併以適應數據層。

你永遠不知道你是否想稍後添加一些業務邏輯。因此，即使您目前沒有進行轉換，最好還是有一個單獨的圖層。