TA貢獻(xiàn)1831條經(jīng)驗(yàn) 獲得超9個贊
使數(shù)據(jù)訪問更加抽象和可移植。ORM實(shí)現(xiàn)類知道如何編寫特定于供應(yīng)商的SQL，因此您不必這樣做。
TA貢獻(xiàn)1856條經(jīng)驗(yàn) 獲得超5個贊
使用ORM的最重要原因是，您可以擁有一個豐富的，面向?qū)ο蟮臉I(yè)務(wù)模型，并且仍然能夠存儲它并針對關(guān)系數(shù)據(jù)庫快速編寫有效的查詢。從我的角度來看，與您可以編寫的高級查詢類型相比，優(yōu)質(zhì)的ORM與其他生成的DAL相比，沒有任何真正的優(yōu)勢。
我正在考慮的一種查詢類型是多態(tài)查詢。一個簡單的ORM查詢可能會選擇數(shù)據(jù)庫中的所有形狀。您會得到一系列形狀。但是根據(jù)其區(qū)分符，每個實(shí)例都是正方形，圓形或矩形。
另一種查詢類型是在單個數(shù)據(jù)庫調(diào)用中急于獲取一個對象以及一個或多個相關(guān)對象或集合的查詢。例如，返回每個形狀對象，并填充其頂點(diǎn)和邊集合。
很抱歉在這里與其他許多人不同意，但是我認(rèn)為代碼生成本身并不是與ORM一起使用的足夠好理由。您可以為代碼生成器編寫或找到許多不錯的DAL模板，這些模板沒有ORM的概念或性能開銷。
或者，如果您認(rèn)為不需要知道如何編寫好的SQL來使用ORM，那么我也不同意。從編寫單個查詢的角度來看，依靠ORM更容易。但是，使用ORM，當(dāng)開發(fā)人員不了解其查詢?nèi)绾闻cORM及其轉(zhuǎn)換為SQL一起使用時，創(chuàng)建性能差的例程太容易了。
具有對多個數(shù)據(jù)庫有效的數(shù)據(jù)層可能是一個好處。不過，這不是我不得不經(jīng)常依賴的人。
最后，我必須重申，根據(jù)我的經(jīng)驗(yàn)，如果您不使用ORM的更高級的查詢功能，則可以使用其他選項(xiàng)來解決剩余的問題，而這將減少學(xué)習(xí)量和CPU周期。
哦，是的，有些開發(fā)人員確實(shí)發(fā)現(xiàn)與ORM一起工作很有趣，因此從讓開發(fā)人員滿意的角度來看，ORM也很不錯。=）
舉報(bào)