要實現Specification Pattern 感覺不用ORM不行，不然不是效能更慘就是得寫更多magic code，但是被ORM效能搞過的人真的很難相信ORM ...orz

然後要完全照DDD方法做小案子感覺真的是殺雞用牛刀...分層+抽象化的結果感覺就是初期有大量 mapping code，也提升閱讀難度。 但小案子不用大案子更不知道該怎麼做orz

我沒用過ORM，只有用過自己手刻的簡易版SELECT INSERT UPDATE DELETE MySQL generation XD
但光是如此就已經可以初窺隔一層Debug的麻煩以及要變化功能時的麻煩XD

ORM對我來說大概分兩類，一種是完全不用寫SQL，邏輯可以用語言本身表示(通常是lambda expression)，我說的ORM一般都是指這種 ，另一種就只做最簡單的物件轉換封裝，還是得寫SQL只是CRUD沒那麼raw。

dynamic sql builder通常後者有機會提供一些helper，但要做logic expression to sql 還是遠遠不夠 ，不過通常也是必然的...

像我自己的就只是懶得每次寫SQL重複要寫的某些東西所以做的包裝XDDD

ORM有效能問題嗎？他只是Wrapper而已啊

最後內部下的還是SQL 要說的話就是可能有效能問題的地方（尤其牽扯到JOIN/loop）ORM下法也要對應改

有的不會只有做Wrapper啊，另外還會Tracking，另外光是expression to sql這部分就有機會沒做好sql optimization

(SQLAlchemyORM)

Tracking都是 in memory 的事情應該還好吧 XD

就經驗來說真的有差，光ORM之間怎麼做wrap都有差，更別提複雜起來背後做的事情，網路上都找得到效能比較啊XD

C# 比EF Core vs dapper

Dapper vs. EF Core - Which is Faster?

golang 比幾個orm

How to Benchmark: dbq vs sqlx vs GORM | Medium

至於易用(可讀?)度vs效能這就千古問題，我工作前五年也覺得ORM很棒，有需要再用SQL就好...直到後來幾次踩到雷又因為牽連太深改不動 (雖然也有部分是當年程式寫太爛，沒做好分層架構) 覺得與其花時間調整ORM效能，我還不如好好研究DB/SQL效能該如何提升，現在就比較喜歡sql+lightweight orm那派 (但想用DDD和specification pattern感覺得走回頭路orz)

你終究都要寫（懂）SQL的...

防SQL Injection跟寫簡單的CRUD用ORM要快很多，簡單的Aggregation也是ORM優，麻煩在使用特殊功能(Partition/Window function/RDB專用功能)

速成/Rapid prototype還是ORM比較優，高效能的東西是還要SQL沒錯，因為本質還是leaky abstraction

yeah，所以我才偏好sql+lightweight ORM，比較好兼顧優點。

但我現在遇到DDD要把商業邏輯往domain層塞，那infra層要實作repo to db 就各種卡 qq