Tại sao bạn nên sử dụng ORM? [đóng cửa]

113

Nếu bạn muốn thúc đẩy những người "chuyên nghiệp" về lý do bạn sử dụng ORM cho quản lý / khách hàng, thì lý do là gì?

Hãy thử và giữ lại một lý do cho mỗi câu trả lời để chúng tôi có thể xem điều gì được bình chọn là lý do tốt nhất

database  orm 
— Simon Munro
nguồn
3
bạn nên làm cho nó một wiki nếu bạn muốn có một cuộc thăm dò
— frankodwyer
+1 để biến nó thành wiki nếu bạn muốn một cuộc thăm dò ý kiến
— cletus
16
Điều gì về con của?
— Brian Matthews
4
Và cũng không có thìa. Không, thực sự, có một vấn đề: hiệu suất. Việc tối ưu hóa các truy vấn DB dễ dàng hơn nhiều khi bạn không phải thông qua ORM. (Tôi không phàn nàn - gần đây đã chuyển đến ORM, tôi chủ yếu là hài lòng với nó, vì mục đích chung, ORM là con đường để đi, nhưng giữ một số cách để chạy các truy vấn gần gũi hơn với các kim loại khi và chỉ khi bạn cần thực hiện)
— Piskvor rời tòa nhà
2
@ UğurGümüşhan, IMHO, lợi ích chính của việc sử dụng ORM là giúp các nhà phát triển làm việc hiệu quả hơn, bằng cách cho phép họ lập trình bằng cùng một ngôn ngữ và mô hình OO mà họ sử dụng trong phần còn lại của ứng dụng. Các thủ tục được lưu trữ không thể cung cấp điều đó, khi chúng tạo mã nhà phát triển bằng ngôn ngữ thủ tục được lưu trữ RDBMS. Vì vậy, họ không thể làm mọi thứ mà một ORM có thể.
— Bill Karwin

Câu trả lời:

53

Làm cho việc truy cập dữ liệu trở nên trừu tượng và di động hơn. Các lớp triển khai ORM biết cách viết SQL dành riêng cho nhà cung cấp, vì vậy bạn không cần phải làm vậy.

— Bill Karwin
nguồn
61
Mặc dù tôi đồng ý rằng đây là một tính năng của ORM, nhưng tôi đề xuất rằng trường hợp sử dụng là khá hạn chế. Tôi chưa bao giờ thực sự sử dụng bất cứ thứ gì ngoài MySql và sqlite trong khoảng một thập kỷ. Tôi nghĩ rằng đó có lẽ là một yêu cầu rất hiếm đối với hầu hết các nhà phát triển.
— troelskn 29/12/09
40
@troelskn: Tôi đồng ý, tôi đã sử dụng nhiều sản phẩm RDBMS, nhưng không bao giờ nhiều hơn một hoặc hai sản phẩm cho mỗi dự án. Vì vậy, tính di động không phải là giá trị thiết thực nhất của việc trừu tượng hóa SQL. Tôi nghĩ rằng nhiều người dùng ORM chỉ đơn giản là muốn tránh viết mã trong SQL.
— Bill Karwin
2
các nhà cung cấp luôn ra mắt các phiên bản / tính năng mới ... chỉ cần một số người giỏi viết phương ngữ và dễ dàng nâng cấp nó là được!
— dotjoe
5
Câu trả lời vô dụng điển hình Tôi tự hỏi tại sao nó được đánh dấu là câu trả lời tốt, có vẻ như anh chàng đặt câu hỏi chỉ cố gắng biện minh với sếp rằng anh ta nên sử dụng ORM :) Câu hỏi của tôi thà là bạn sẽ gặp phải vấn đề gì với Hibernate stackoverflow.com/questions/6477170/…
— user310291
2
@ user310291: OP không hỏi vấn đề hay cạm bẫy, anh ấy yêu cầu lợi ích của việc sử dụng ORM. Tất nhiên có những ưu và khuyết điểm, nhưng anh ấy đã yêu cầu những ưu điểm. Thành thật mà nói, tôi rất ngạc nhiên khi câu trả lời này được chấp nhận và nhận được nhiều lượt ủng hộ như nó đã làm, bởi vì tôi sẽ không tính nó là lợi ích chính của ORM.
— Bill Karwin
83

Lý do quan trọng nhất để sử dụng ORM là để bạn có thể có một mô hình kinh doanh hướng đối tượng, phong phú và vẫn có thể lưu trữ nó và viết các truy vấn hiệu quả một cách nhanh chóng dựa trên cơ sở dữ liệu quan hệ. Theo quan điểm của tôi, tôi không thấy bất kỳ lợi thế thực sự nào mà một ORM tốt mang lại cho bạn khi so sánh với các DAL được tạo khác ngoài các loại truy vấn nâng cao mà bạn có thể viết.

Một loại truy vấn tôi đang nghĩ đến là truy vấn đa hình. Một truy vấn ORM đơn giản có thể chọn tất cả các hình dạng trong cơ sở dữ liệu của bạn. Bạn nhận được một bộ sưu tập các hình dạng trở lại. Nhưng mỗi trường hợp là một hình vuông, hình tròn hoặc hình chữ nhật tùy theo dấu hiệu phân biệt của nó.

Một loại truy vấn khác sẽ là một loại truy vấn háo hức tìm nạp một đối tượng và một hoặc nhiều đối tượng hoặc bộ sưu tập có liên quan trong một lệnh gọi cơ sở dữ liệu. Ví dụ: Mỗi đối tượng hình dạng được trả về với các tập hợp đỉnh và cạnh của nó được điền.

Tôi rất tiếc khi không đồng ý với rất nhiều người khác ở đây, nhưng tôi không nghĩ rằng bản thân việc tạo mã là một lý do đủ tốt để sử dụng ORM. Bạn có thể viết hoặc tìm nhiều mẫu DAL tốt cho trình tạo mã không có khái niệm hoặc chi phí hiệu suất như ORM.

Hoặc, nếu bạn nghĩ rằng bạn không cần biết cách viết SQL tốt để sử dụng ORM, một lần nữa, tôi không đồng ý. Có thể đúng rằng từ quan điểm viết các truy vấn đơn lẻ, việc dựa vào ORM dễ dàng hơn. Tuy nhiên, với ORM, quá dễ dàng để tạo ra các quy trình hoạt động kém khi các nhà phát triển không hiểu cách truy vấn của họ hoạt động với ORM và SQL mà họ dịch sang.

Có một lớp dữ liệu hoạt động dựa trên nhiều cơ sở dữ liệu có thể là một lợi ích. Tuy nhiên, nó không phải là thứ mà tôi phải dựa vào đó thường xuyên.

Cuối cùng, tôi phải nhắc lại rằng theo kinh nghiệm của tôi, nếu bạn không sử dụng các tính năng truy vấn nâng cao hơn của ORM, có các tùy chọn khác giải quyết các vấn đề còn lại với ít học hơn và ít chu kỳ CPU hơn.

Ồ đúng rồi, một số nhà phát triển thấy làm việc với ORM's rất thú vị, vì vậy ORM's cũng tốt từ quan điểm giữ cho các nhà phát triển của bạn hài lòng. =)

— Chuck
nguồn
1
Nói hay lắm. Mặc dù người đăng ban đầu đã đặc biệt tìm kiếm "ưu điểm" chứ không phải "nhược điểm", tôi đã thấy một số SQL KHÓ KHĂN được tạo ra do không hiểu tác động của CÁCH bạn sử dụng ORM. Đối với tôi, lợi ích lớn nhất là đối với các giao dịch CRUD đơn giản, vốn chiếm phần lớn mã DAL của bạn cho các hệ thống giao dịch. Tôi nghĩ rằng bạn đang phân tách giữa ORM thuần túy và các phương pháp DAL được tạo khác. Tôi nghĩ bất cứ thứ gì giúp bạn dịch giữa các đối tượng và DB có thể được coi là ORM, nó chỉ là một mô hình hoạt động khác.
— Doug Lampe
1
@Doug - Tôi nghĩ rằng sự khác biệt mà tôi theo đuổi là một DAL đơn giản bao gồm nhiều hơn một chút so với CRUD SQL được tạo trong khi ORM chứa nhiều nội dung trừu tượng hơn như thuộc tính điều hướng, tính bền vững của bộ sưu tập, ngôn ngữ truy vấn chuyên dụng, bộ nhớ đệm, v.v. - Một cách tốt hơn việc nêu quan điểm của tôi theo quan sát của bạn có thể là mặc dù đúng là sử dụng nhiều tính năng hơn của ORM cho phép bạn triển khai nhanh hơn, nhưng không có nghĩa là chấp nhận được nếu bạn không biết về cách hoạt động của các tính năng đó. Có lẽ vì phần tóm tắt của ORM bị rò rỉ nhiều hơn hầu hết. ( En.wikipedia.org/wiki/Leaky_abstraction )
— Chuck
vui lòng giải thích thêm về vấn đề này: "nếu bạn không sử dụng các tính năng truy vấn nâng cao hơn của ORM, có các tùy chọn khác giải quyết các vấn đề còn lại". cũng như người tạo ra hibernate gavin king nói: "Thật vậy, các hệ thống như Hibernate được thiết kế có chủ ý như" phần trừu tượng bị rò rỉ "để có thể dễ dàng kết hợp trong SQL gốc khi cần thiết. Sự rò rỉ của phần trừu tượng ORM là một tính năng, không phải lỗi ! " - reddit.com/r/programming/comments/2cnw8x/…
— forest_mole
1) Cái này cũ rồi. Hồi đó, ORM có tất cả các tính năng (bộ nhớ đệm, truy vấn, hàng loạt, v.v.). Truy vấn IMHO, dựa trên đối tượng, đa hình là tính năng ORM duy nhất mà gen mã (ánh xạ ADO rõ ràng) không thể dễ dàng cung cấp. 2) Mặc dù một số lỗ hổng hữu ích đã được cố ý để lại, nhưng cũng có những điểm xấu và tính năng nâng cao cần thiết tạo ra một đường cong học tập cao trong ORM. Vì vậy, câu trả lời của tôi là sử dụng gen mã thay vì ORM trừ khi bạn cần truy vấn nâng cao. *) Thời điểm hiện tại, có đủ sự đa dạng trong ORM mà tính năng phù hợp được đặt cho nhóm của bạn có thể đã có sẵn. Nhóm của tôi hiện đang thích Linq2DB.
— Chuck
60

Tăng tốc độ phát triển. Ví dụ: loại bỏ mã lặp lại như ánh xạ các trường kết quả truy vấn với các thành viên đối tượng và ngược lại.

— Bill Karwin
nguồn
3
Mã lặp lại rất tệ, nhưng bạn có thể không xây dựng một sự trừu tượng để loại bỏ điều này? Ví dụ: bạn có thể có một đối tượng bảng / kết quả truy vấn sẽ cung cấp cho bạn các hàng mà sau đó bạn có thể thực hiện công việc với. Các ORM dường như chia nhỏ các hàng trong các cá thể lớp riêng lẻ, thay vì đi vào phần trừu tượng đã chọn của DB, đó là các bảng / hàng kết quả truy vấn. Tôi không nói rằng điều này có nghĩa là ORM không tốt, nhưng tôi không chắc chỉ riêng điều này là lý do để sử dụng chúng.
— Benjohn
@Benjohn, tôi đồng ý rằng giải pháp ORM coi các hàng riêng lẻ là đối tượng, trong khi RDBMS xử lý các tập hợp hàng như một thực thể. Có những điều bạn có thể làm trong tư duy RDBMS mà bạn không thể làm trong tư duy OO.
— Bill Karwin
Điều này giống như mua cả một chiếc ô tô chỉ để sử dụng cốp xe, có nhiều cách để tránh công việc lặp đi lặp lại
— mohas 6/1018
15

Hỗ trợ đóng gói OO các quy tắc nghiệp vụ trong lớp truy cập dữ liệu của bạn. Bạn có thể viết (và gỡ lỗi) các quy tắc nghiệp vụ bằng ngôn ngữ ứng dụng ưa thích của mình, thay vì ngôn ngữ trình kích hoạt và thủ tục được lưu trữ rườm rà.

— Bill Karwin
nguồn
Tuy nhiên, bạn không muốn có các quy tắc kinh doanh của mình trong cơ sở dữ liệu? Đó là lợi ích của cơ sở dữ liệu, đúng không: nhiều máy khách có thể sử dụng cùng một giao diện được cung cấp bởi DBMS. Nếu nhiều logic giao diện của bạn bị khóa trong mã ORM của một ứng dụng khách cụ thể, nó không có trong cơ sở dữ liệu và các ứng dụng khách khác không sử dụng nó. Cue front office back office nghỉ (một mô hình khách hàng vượt quá giới hạn với mô hình khác).
— Benjohn
1
@Benjohn, tôi có xu hướng đưa các quy tắc nghiệp vụ đơn giản vào cơ sở dữ liệu, nhưng các quy tắc phức tạp hơn không dễ hình thành trong các ràng buộc khai báo. Ví dụ: "khách hàng được giảm giá 10% cho toàn bộ đơn đặt hàng lần đầu tiên họ mua nhiều hơn ba đôi quần lọt khe từ cùng một thương hiệu." Bạn sẽ đưa quy tắc nghiệp vụ đó vào cơ sở dữ liệu như thế nào (hãy nhớ rằng một câu trả lời liên quan đến các thủ tục được lưu trữ là rất khó hiểu).
— Bill Karwin
Bây giờ là năm 2020, tôi không thấy bất kỳ ai sử dụng các thủ tục được lưu trữ nữa. Vì vậy, bạn có điểm vẫn còn đứng?
— ospider
Tôi nghĩ rằng quan điểm của tôi là mọi người không sử dụng các thủ tục được lưu trữ, họ sử dụng mã ứng dụng. Bạn đã hiểu điều gì đó khác biệt?
— Bill Karwin
8

Bạn có thể chuyển sang phần mềm cơ sở dữ liệu khác nhau một cách dễ dàng vì bạn đang phát triển đến một phần mềm trừu tượng.

— Matt Fenelon
nguồn
41
Trong hơn 30 năm làm công việc cơ sở dữ liệu, tôi chưa một lần phải làm điều này.
— HLGEM
4
Không có nghĩa là không thể! :)
— Matt Fenelon
2
@HLGEM nghĩa là bạn đang đóng các lựa chọn cho khách hàng. Nó thực sự có thể xảy ra, chỉ trong 3 năm webapps làm việc, chúng tôi đã xây dựng phần mềm di động sử dụng ORMs
— Alfabravo
1
Bạn có thể tìm thấy nó hữu ích trong trường hợp bạn muốn thử nghiệm chạy trên một cơ sở dữ liệu trong bộ nhớ
— Carlos Parraga
Có thể một số trường hợp của cùng một phần mềm có thể sử dụng các cơ sở dữ liệu khác nhau. Nhưng việc di chuyển dữ liệu hiện có từ phần mềm DB này sang phần mềm DB khác thực sự hiếm khi xảy ra. Và khi nó xảy ra, nhiều ORM không thực sự hỗ trợ bạn điều đó.
— jlh
4

Sao cho mô hình đối tượng và mô hình bền bỉ của bạn khớp với nhau.

— cletus
nguồn
1
Có thể vì vậy mà sự kiên trì của bạn là minh bạch đối với mô hình đối tượng của bạn
— S.Lott
4

Hạnh phúc phát triển, IMO. ORM tóm tắt rất nhiều thứ bạn phải làm trong SQL. Nó giữ cho cơ sở mã của bạn đơn giản: ít tệp nguồn hơn để quản lý và các thay đổi giản đồ không yêu cầu hàng giờ bảo trì.

Tôi hiện đang sử dụng ORM và nó đã thúc đẩy quá trình phát triển của tôi.

— tò mò
nguồn
3

Để giảm thiểu sự trùng lặp của các truy vấn SQL đơn giản.

— Tim Wardle
nguồn
3

Lý do tôi đang xem xét nó là để tránh mã được tạo từ các công cụ DAL của VS2005 (ánh xạ lược đồ, TableAdapters).

DAL / BLL mà tôi đã tạo hơn một năm trước đang hoạt động tốt (đối với những gì tôi đã xây dựng nó) cho đến khi người khác bắt đầu sử dụng nó để tận dụng một số chức năng đã tạo (mà tôi không biết ở đó)

Có vẻ như nó sẽ cung cấp một giải pháp trực quan và rõ ràng hơn nhiều so với giải pháp DAL / BLL từ http://wwww.asp.net

Tôi đã nghĩ về việc tạo trình tạo mã SQL Command C # DAL của riêng mình, nhưng ORM trông giống như một giải pháp thanh lịch hơn

— Dan McClain
nguồn
2

Biên dịch và kiểm tra các truy vấn.

Khi công cụ cho ORM được cải thiện, bạn sẽ dễ dàng xác định tính đúng đắn của các truy vấn nhanh hơn thông qua các thử nghiệm và lỗi thời gian biên dịch.

Việc biên dịch các truy vấn của bạn sẽ giúp các nhà phát triển tìm ra lỗi nhanh hơn. Đúng? Đúng. Việc biên dịch này có thể thực hiện được vì các nhà phát triển hiện đang viết các truy vấn bằng mã bằng cách sử dụng các đối tượng hoặc mô hình nghiệp vụ của họ thay vì chỉ các chuỗi câu lệnh như SQL hoặc SQL.

Nếu sử dụng các mẫu truy cập dữ liệu chính xác trong .NET, bạn có thể dễ dàng kiểm tra đơn vị logic truy vấn của mình dựa trên bộ sưu tập bộ nhớ. Điều này giúp tăng tốc độ thực thi các bài kiểm tra của bạn vì bạn không cần phải truy cập cơ sở dữ liệu, thiết lập dữ liệu trong cơ sở dữ liệu hoặc thậm chí tạo ra một bối cảnh dữ liệu đầy đủ. [EDIT] Điều này không đúng như tôi nghĩ nó là đơn vị kiểm tra trong trí nhớ có thể đưa ra những thách thức khó vượt qua. Nhưng tôi vẫn thấy các bài kiểm tra tích hợp này dễ viết hơn những năm trước. [/ EDIT]

Điều này ngày nay chắc chắn có liên quan hơn một vài năm trước khi câu hỏi được đặt ra, nhưng đó có thể chỉ là trường hợp của Visual Studio và Entity Framework nơi mà kinh nghiệm của tôi nằm. Thêm môi trường của riêng bạn nếu có thể.

— Chuck
nguồn
1

Hãy tóm tắt các sql đi 95% thời gian để không phải ai trong nhóm cũng cần biết cách viết các truy vấn cụ thể cho cơ sở dữ liệu siêu hiệu quả.

— Jared
nguồn
1

Tôi nghĩ rằng có rất nhiều điểm tốt ở đây (tính di động, dễ phát triển / bảo trì, tập trung vào mô hình kinh doanh OO, v.v.), nhưng khi cố gắng thuyết phục khách hàng hoặc ban quản lý của bạn, tất cả chỉ nằm ở việc bạn sẽ tiết kiệm được bao nhiêu tiền bằng cách sử dụng một ORM .

Thực hiện một số ước tính cho các nhiệm vụ điển hình (hoặc thậm chí các dự án lớn hơn có thể sắp xảy ra) và bạn (hy vọng!) Sẽ nhận được một số đối số cho việc chuyển đổi khó có thể bỏ qua.

— Anders Fjeldstad
nguồn
0

các lớp .net sử dụng các mẫu mã smith

http://nettiers.com/default.aspx?AspxAutoDetectCookieSupport=1

Tại sao mã một cái gì đó có thể được tạo ra.

— Jobo
nguồn
Ặc. Chúng tôi đã sử dụng Net Tiers cho một dự án thương mại lớn và tôi thực sự khuyên bạn không nên sử dụng nó. Vấn đề là nó không thể kết hợp được. Bạn muốn truy vấn các đối tượng Foo và Bar? Bạn không thể viết các phép nối, bạn phải đưa ra các truy vấn riêng biệt cho từng loại đối tượng mà bạn muốn. Điều này dẫn đến rất nhiều lệnh gọi đến cơ sở dữ liệu, có thể phá vỡ hiệu suất và tính nguyên tử. Xấu xấu xấu. Tránh ra.
— Judah Gabriel Himango
0

thuyết phục họ rằng bạn sẽ tiết kiệm được bao nhiêu thời gian / tiền bạc khi có thay đổi và bạn không phải viết lại SQL của mình vì công cụ ORM sẽ làm điều đó cho bạn

— zmf
nguồn
0

Tôi nghĩ một khuyết điểm là ORM sẽ cần một số cập nhật trong POJO của bạn. chủ yếu liên quan đến lược đồ, quan hệ và truy vấn. vì vậy tình huống mà bạn không được cho là thực hiện các thay đổi trong các đối tượng mô hình, có thể là do nó được chia sẻ giữa các đối tượng khác trên máy khách và máy chủ dự án hoặc b / w. vì vậy trong những trường hợp như vậy, bạn sẽ cần phải chia nó thành hai cấp, điều này sẽ đòi hỏi những nỗ lực bổ sung.

tôi là một nhà phát triển Android và như bạn biết, các ứng dụng dành cho thiết bị di động thường có kích thước không lớn, vì vậy nỗ lực bổ sung này để tách biệt mô hình thuần túy và mô hình bị ảnh hưởng bởi orm dường như không có giá trị đầy đủ.

tôi hiểu câu hỏi đó là chung chung. nhưng các ứng dụng dành cho thiết bị di động cũng nằm trong ô chung.

— Shailendra Singh Rajawat
nguồn
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookie và Chính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.