Lợi ích của việc sử dụng trừu tượng hóa cơ sở dữ liệu bằng ORM là gì? [đóng cửa]

Tôi bắt đầu sử dụng ORM được đề xuất bởi khung mà tôi chọn, và mặc dù tôi thích ý tưởng về lớp trừu tượng được thêm vào mà ORM cung cấp, tôi bắt đầu nhận ra điều này thực sự có nghĩa là gì. Điều đó có nghĩa là tôi không còn làm việc với cơ sở dữ liệu của mình (mysql) và mọi tính năng dành riêng cho mysql đã biến mất, ngoài cửa sổ, giống như chúng không tồn tại.

Ý tưởng mà ORM có là nó đang cố gắng giúp tôi bằng cách biến mọi thứ thành cơ sở dữ liệu. Điều này nghe có vẻ tuyệt vời, nhưng thường có một lý do tại sao tôi chọn một hệ thống cơ sở dữ liệu cụ thể. Nhưng bằng cách đi theo lộ trình bất khả tri của cơ sở dữ liệu, ORM lấy mẫu số chung thấp nhất, có nghĩa là tôi kết thúc với bộ tính năng nhỏ nhất (những tính năng được hỗ trợ bởi tất cả các cơ sở dữ liệu).

Điều gì sẽ xảy ra nếu tôi biết rằng về lâu dài tôi sẽ không chuyển đổi cơ sở dữ liệu cơ bản? Tại sao không truy cập các tính năng cụ thể của cơ sở dữ liệu, quá?

Tôi thấy nó theo cùng một cách. Bất kỳ sự trừu tượng hóa nào không cho phép bạn có được bên dưới nó khi cần thiết là xấu xa, bởi vì nó dẫn đến tất cả các loại đảo ngược trừu tượng xấu xí trong mã của bạn.

Tại nơi làm việc, chúng tôi có một ORM tại nhà hoạt động khá tốt, nhưng trong thời gian chúng tôi cần một thứ gì đó mà các tính năng của nó không cung cấp rõ ràng, có một phương pháp lấy một chuỗi và thả nó trực tiếp vào truy vấn mà nó tạo ra, cho phép để sử dụng SQL thô khi cần thiết.

IMO bất kỳ ORM nào không có tính năng này không xứng đáng với các bit được biên dịch từ đó.

ORM lấy mẫu số chung thấp nhất

Tôi phải không đồng ý với tuyên bố của bạn. Tôi sẽ lấy nHibernate làm ví dụ. Khung này hỗ trợ rất nhiều cơ sở dữ liệu, bao gồm cả những cơ sở dữ liệu phổ biến nhất, bất kể phiên bản (và các tính năng được hỗ trợ), giống như hầu hết các ORM.

Ghi chú nhanh: bạn chỉ đề cập đến sự trừu tượng hóa cơ sở dữ liệu. Đó là một trong nhiều lợi ích, nhưng tôi thực sự nghĩ rằng các tính năng hướng đối tượng mạnh hơn (ví dụ: kế thừa). Và You design your domain model first...

... Trở lại sự trừu tượng. Nó không phải là mẫu số chung thấp nhất. Trong nHibernate , bạn có phương ngữ. Nó cho phép bạn sử dụng cùng một mã để truy vấn các cơ sở dữ liệu khác nhau. Phương ngữ chăm sóc quản lý tính năng cho bạn. Phát biểu đúng là như vậy a given dialect will try to use all the power of a given database system.

Như một ví dụ điển hình SqlServer2005, khi được giới thiệu, đã tận dụng các tính năng phân trang mới của SQL Server 2005. Sử dụng phương ngữ đó thay vì SqlServer2000chỉ tăng hiệu suất của bạn.

Tất nhiên cũng có trường hợp ngoại lệ, nhưng tôi đã không gặp phải một trường hợp nào trong nhiều năm làm việc với nHibernate và các ứng dụng của tôi rất tập trung vào dữ liệu.

Ý tưởng rất gọn gàng, nhưng tôi chưa bao giờ được chuyển sang sử dụng công cụ ORM. Nó không phải là vấn đề đối với tôi để tự viết SQL (hoặc xử lý bất kỳ lưu trữ nào được sử dụng). Nhưng, tôi có sự thoải mái khi làm việc với số lượng dự án nhỏ hơn với tuổi thọ sản phẩm dài hơn, do đó, một khi thao tác SQL và DB được mã hóa bằng tay được thực hiện, nó đã được thực hiện. Thêm vào đó, rõ ràng bạn có thể xử lý bất kỳ truy vấn SQL trực tiếp nào bạn cần mà không cần phải điều chỉnh quy trình của bạn theo cách suy nghĩ của công cụ ORM.

Vì vậy, tôi đoán các câu hỏi nên có trước khi bạn nhảy vào một:

Bạn có thực sự đạt được bất cứ điều gì từ việc sử dụng chúng? Đó là, bạn có tiết kiệm đủ số lượng nỗ lực bằng cách triển khai một công cụ ORM để làm cho nó đáng để sử dụng và để làm cho nó đáng để thêm một sự phức tạp thêm vào hệ thống của bạn không? (điều này đặc biệt đúng với các ứng dụng thương mại, trong đó 'phần bổ sung' hiện là một vectơ bổ sung cho các vấn đề hỗ trợ tiềm năng)

Và sau đó, lớp trừu tượng thêm có ảnh hưởng tiêu cực đến ứng dụng không? Nó sẽ chậm hơn SQL mã hóa, v.v.

O / RM đã bị chỉ trích thường xuyên. Ted Neward gọi nó là " Việt Nam của Khoa học Máy tính " vài năm trước. O / RM

bắt đầu tốt, trở nên phức tạp hơn khi thời gian trôi qua và trước khi kéo dài người dùng vào một cam kết không có điểm phân định rõ ràng, không có điều kiện thắng rõ ràng và không có chiến lược thoát rõ ràng.

Trừ khi bạn chỉ viết bản đồ ad-hoc của riêng bạn (đó là một giải pháp tốt trong nhiều trường hợp, như những người khác đã nói), bạn có thể xem xét các lựa chọn thay thế như sử dụng cơ sở dữ liệu không liên quan. Một số người nói rằng cơ sở dữ liệu đối tượng thực sự tốt hơn, các từ thông dụng khác được đề cập trong ngữ cảnh này là LINQ, Ruby và Hướng dẫn D. Tôi cho rằng, trái ngược với cơ sở dữ liệu quan hệ thực sự, có cơ sở dữ liệu đối tượng thực sự. Nhưng trong thực tế tôi thấy rằng mô hình hóa dữ liệu khái niệm - nghĩa là tìm ra, những đối tượng trong thế giới thực mà bạn muốn lưu trữ dữ liệu và cách các đối tượng này liên quan đến nhau - quan trọng hơn là tìm hiểu cách thể hiện mô hình khái niệm của bạn trong bất kỳ lập trình hoặc ngôn ngữ cơ sở dữ liệu.

Cái gì thay thế?

Đây là một khái niệm thú vị. Bằng cách trừu tượng hóa các tính năng của cơ sở dữ liệu cơ bản, chúng tôi chắc chắn mất một số tính năng của việc triển khai cơ sở dữ liệu cụ thể. (Chúng ta có nên phụ thuộc vào các tính năng cơ sở dữ liệu cụ thể hay không là một đối số khác) Tôi đoán điều này có thể được giải quyết bằng các ORM dành riêng cho cơ sở dữ liệu cho phép bạn truy cập các tính năng cụ thể, nhưng điều đó có thể gây ra nhiều rắc rối hơn giá trị sai hướng.

Vào cuối ngày, bạn phải tự hỏi - cái gì thay thế?

Chúng ta có nên ngừng sử dụng ORM và quay lại viết tất cả các truy cập cơ sở dữ liệu không? Chắc chắn chúng tôi có thể mất quyền truy cập vào một vài tính năng cơ sở dữ liệu thông qua ORM, nhưng bạn luôn có thể truy cập những tính năng này bằng các kỹ thuật trường học cũ. Cuối cùng, lợi nhuận bạn đạt được trong năng suất hoàn toàn vượt trội hơn những nhược điểm.

Một ORM về cơ bản lên tới " Các thủ tục chưa được bảo vệ ". Ở đó, tôi đặt ra một thuật ngữ.

Mọi thứ ORM làm, bạn có thể sao chép với Lượt xem, Kích hoạt và Thủ tục lưu trữ. Chúng giúp trừu tượng hóa SQL thô và có thể giữ cho các cơ sở dữ liệu được chuẩn hóa nhất quán. Nhưng nó chỉ hoạt động tốt cho các trường hợp đơn giản. Nếu có quá nhiều dữ liệu mach để xử lý, chúng có thể trở thành một cống hiệu suất. (Các ORM trong PHP thường có phía tập lệnh dữ liệu, vì các chuỗi trình tạo SQL không thể trừu tượng hóa mọi thứ.)

Nhưng như thường lệ, tất cả phụ thuộc vào ứng dụng và nhiệm vụ trong tay.

Một điều gây tổn thương khi sử dụng ORM là nhiều người hâm mộ của họ có xu hướng tuyên bố rằng chúng tôi không còn cần phải biết lý thuyết SQL và RDB. Các kết quả khác nhau từ hài hước đến thảm khốc hoàn toàn. Và điều này bất chấp hàng triệu lần ORM 'sản xuất và đánh giá rằng chúng ta phải biết rõ lý thuyết SQL và RDB để sử dụng và định cấu hình ORM đúng cách.

Tại sao mọi người sử dụng một công cụ có công dụng của nó trên nhiều, nhưng không phải tất cả các bối cảnh thành một viên đạn bạc có thể áp dụng phổ biến đều nằm ngoài tôi.

Năm ngoái tôi đã làm việc trên một ứng dụng nội bộ thay đổi thường xuyên và tôi rất vui khi chúng tôi sử dụng ORM. Ứng dụng này là một ứng dụng hỗ trợ cho nhóm quản lý thay đổi và khi dự án lớn hơn phát triển, ứng dụng nhỏ của chúng tôi có các yêu cầu mới cho các tình huống không tồn tại và không thể lường trước được vài tháng trước.

Nhờ ORM ( Propel , trong PHP), chúng tôi đã phân tách một số logic cho mã, do đó, một hàm đã thêm phần "là bản ghi hợp lệ" của truy vấn, một phần bảo mật khác ("chỉ hiển thị các bản ghi này nếu người dùng có các khả năng này "), ... Nếu cấu trúc cơ bản thay đổi (một trường bổ sung cần được xem xét cho" tính hợp lệ của bản ghi "), chúng tôi chỉ phải thay đổi một hàm, không phải hai mươi mệnh đề SQL.

Chúng tôi xuất phát từ một tình huống mà tất cả các mệnh đề SQL (tốt, hầu hết) được lưu trữ trong một tệp XML riêng biệt, vì vậy "các thay đổi cơ sở dữ liệu sẽ dễ xử lý". Hãy tin tôi, họ đã không. Một phần kinh khủng đến nỗi tôi phải gửi nó cho The Daily WTF .

Nếu một truy vấn quá phức tạp để thể hiện với Tiêu chí Propel hoặc chúng tôi cần một số tính năng dành riêng cho nhà cung cấp (chủ yếu là tìm kiếm toàn văn bản, vì chúng tôi đang sử dụng MySQL), thì điều này không có vấn đề gì với Propel. Bạn có thể thêm tiêu chí tùy chỉnh hoặc khi thực sự cần thiết, chúng tôi đã sử dụng SQL thô ( giờ đây thậm chí còn dễ dàng hơn để kết hợp với các đối tượng Propel thực tế). Bạn có thể dễ dàng thêm các tiện ích bổ sung dành riêng cho nhà cung cấp của mình vào các lớp được tạo, để bạn có cả hai thế giới tốt nhất: không có SQL trong mã ứng dụng của bạn, nhưng với tất cả các khả năng của công cụ cơ sở dữ liệu của bạn.

Nhưng vấn đề là bạn phải lập trình ra khỏi cơ sở dữ liệu, nghĩa là bạn không cần phải nghĩ như bạn đang ở trong cơ sở dữ liệu.

Bây giờ tôi làm việc trong C # và sử dụng LINQ rất nhiều, rất nhiều phương pháp lưu loát. Tôi không cần phải suy nghĩ về cách các đối tượng của tôi được lưu trữ hoặc tìm thấy, hoặc thậm chí được lưu ở cấp chương trình và rất ít ở cấp độ doanh nghiệp.

Thông thường các phương thức được cung cấp bởi chính Cơ sở dữ liệu cụ thể được sử dụng trong Trình kết nối DB, do đó bạn có được những tối ưu hóa đó mà không cần biết chúng là gì.

Bạn vẫn có thể viết các hàm DB. Thường thì bạn chỉ có thể ánh xạ chúng qua.

Và trên hết, việc phân tách như thế cho phép kiểm tra và buộc bạn (một chút) viết mã có cấu trúc tốt hơn

ORMs có thể cung cấp cho bạn truy cập vào cơ sở dữ liệu cụ thể các tính năng là tốt, nó phụ thuộc vào ORM bạn đang sử dụng và những tính năng nó cung cấp.

Ví dụ, trong dự án hiện tại tôi đang làm việc, chúng tôi đang sử dụng API liên tục Java và Hibernate. Mặc dù vậy, chúng tôi sử dụng một số tính năng cụ thể của cơ sở dữ liệu, chẳng hạn như tìm kiếm trong các bảng có soundex.

Đối với tôi, lợi ích chính của việc sử dụng ORM không nhất thiết là nó làm cho cơ sở dữ liệu ứng dụng trở nên bất khả tri (mặc dù đó cũng là một điều tốt), nhưng phần lớn tôi không phải suy nghĩ về cách mọi thứ được lưu trữ và lấy lại.

Tuy nhiên , đến một lúc nào đó bạn rất có thể phải suy nghĩ về điều này bằng mọi cách, tùy thuộc vào yêu cầu cho ứng dụng của bạn. ORM không phải là phép thuật.

Tôi đã viết riêng của mình để giúp tôi chọn và chèn dễ dàng hơn.

Evey db điều cụ thể có sẵn. Tôi chỉ cần tự viết truy vấn mà thư viện hỗ trợ cho tôi (tôi có thể sử dụng '?' Và params thay vì tự đặt tên cho một tham số và sử dụng .Add)

Tôi đoán một nửa của tôi hút một nửa hữu ích. Tôi nhận được một số trợ giúp trong thế giới ORM và thực hiện các phần quan trọng trong thế giới truy vấn.

Viết mã để chèn và chọn, cập nhật nội tuyến hoặc với các procs được lưu trữ và ánh xạ chúng trở lại thông qua DAL là tiêu chuẩn dài hơn thay vì chỉ có lợi trong trường hợp ngoại lệ. Các ORM có sẵn, cơ sở dữ liệu hỗ trợ và ngôn ngữ câu hỏi bạn nên hỏi tại sao bạn không sử dụng ORM?

Chúng được tiêu chuẩn hóa, phổ quát, hoặc được chỉ định hoặc chung chung. hơn nữa nó nhanh hơn và dễ thực hiện hơn Tôi đã sử dụng cận âm, linq-to-sql và khung thực thể. Nó cho phép nhà phát triển tập trung vào logic và các quy tắc kinh doanh thay vì ánh xạ cơ sở dữ liệu.

Hai xu của tôi (đơn giản):

1: Có ORMS và có ORMS. Một số ORMS dựa trên Active Record, một số khác dựa trên Data Mapper - bản thân nó là một sự cân nhắc có liên quan, nhưng một yêu cầu một số điều tra để hiểu được ý nghĩa. Nói chung - kinh nghiệm của tôi về PHP là ORMS hỗ trợ cái trước, ít cái nào hỗ trợ cái sau. Các ORM dựa trên Bản ghi hoạt động dường như có một trong hai hiệu ứng - chúng hoặc không chuẩn hóa cơ sở dữ liệu hoặc gọi rất nhiều lớp để hỗ trợ các tương tác đối tượng.

2: Ưu điểm của ORM giảm dần trong mối tương quan trực tiếp đến mức độ phức tạp của truy vấn bạn cần chạy. Khi bạn có một mối quan hệ đơn giản tốt đẹp - tức là Người dùng -> Bài đăng, họ có thể làm việc rất tốt. Điều này (IMO) là lý do tại sao hầu hết các ORM / khung sử dụng các ví dụ như thế này. Tuy nhiên, khi bạn cần chạy các truy vấn phức tạp, lượng ORMQL bạn cần tạo tương đương với độ dài chuỗi của truy vấn SQL thông thường - nhưng ít hiệu suất hơn do biểu đồ đối tượng chạy truy vấn, loại này đánh bại điểm của trừu tượng hóa. Vì vậy, một cách ngắn gọn - ORM là tuyệt vời cho 30-50% nhiệm vụ cơ sở dữ liệu đầu tiên của bạn - nhưng khủng khiếp cho lần cuối. Tôi nghĩ rằng đây là một lý do tại sao AR rất phổ biến.

3: Tại sao phải ẩn khỏi cơ sở dữ liệu? Bạn có sử dụng ngôn ngữ phía máy chủ để trừu tượng javascript không?

Cá nhân tôi trộn các cách tiếp cận đó:

• sử dụng ORM cho những điều cơ bản, tải "người dùng"
• sử dụng một DAO có chứa một số truy vấn SQL được nướng sẵn (ví dụ: selectLike, selectWhere).
• mở rộng DAO khi cần thiết để thêm các truy vấn tùy chỉnh cụ thể hơn nhưng có thể sử dụng lại
• Cung cấp quyền truy cập cơ sở dữ liệu đơn giản thông qua truy vấn DAO - tức là $ data = Dao-> (chuỗi sql của bạn) để thực hiện một truy vấn tắt.

Đã nói tất cả, Doctrine 2 sắp ra mắt, trông thật sự thú vị.

Bạn có thể sử dụng các khung công cụ ánh xạ SQL như myBatis nếu bạn muốn sử dụng các tính năng sql.