Có lý do chính đáng nào để không sử dụng ORM không? [đóng cửa]

Trong quá trình học việc của mình, tôi đã sử dụng NHibernate cho một số dự án nhỏ hơn mà tôi chủ yếu tự viết mã và thiết kế. Bây giờ, trước khi bắt đầu một số dự án lớn hơn, cuộc thảo luận đã nảy sinh cách thiết kế quyền truy cập dữ liệu và có nên sử dụng lớp ORM hay không. Vì tôi vẫn đang trong thời gian học việc và vẫn coi mình là người mới bắt đầu lập trình doanh nghiệp, nên tôi không thực sự cố gắng thúc đẩy theo quan điểm của mình, đó là việc sử dụng một trình ánh xạ quan hệ đối tượng cho cơ sở dữ liệu có thể dễ dàng phát triển hơn rất nhiều. Các lập trình viên khác trong nhóm phát triển có kinh nghiệm hơn tôi rất nhiều, vì vậy tôi nghĩ tôi sẽ chỉ làm theo những gì họ nói. :-)

Tuy nhiên, tôi không hoàn toàn hiểu hai trong số những lý do chính khiến tôi không sử dụng NHibernate hoặc một dự án tương tự:

1. Người ta chỉ có thể xây dựng các đối tượng truy cập dữ liệu của riêng mình bằng các truy vấn SQL và sao chép các truy vấn đó ra khỏi Microsoft SQL Server Management Studio.
2. Gỡ lỗi ORM có thể khó.

Vì vậy, tất nhiên tôi có thể chỉ xây dựng lớp truy cập dữ liệu của mình với rất nhiều SELECTs, v.v., nhưng ở đây tôi bỏ lỡ lợi thế của kết hợp tự động, các lớp proxy tải chậm và nỗ lực bảo trì thấp hơn nếu bảng có một cột mới hoặc một cột bị đổi tên. (Đang cập nhật rất nhiều SELECT, INSERTvà UPDATEtruy vấn vs cập nhật các cấu hình bản đồ và có thể sắp xếp các lớp học kinh doanh và DTOs.)

Ngoài ra, sử dụng NHibernate, bạn có thể gặp phải những vấn đề không lường trước nếu bạn không hiểu rõ về framework. Đó có thể là, ví dụ, tin tưởng Table.hbm.xml nơi bạn đặt độ dài của chuỗi để được xác thực tự động. Tuy nhiên, tôi cũng có thể hình dung ra các lỗi tương tự trong lớp truy cập dữ liệu dựa trên truy vấn SqlConnection “đơn giản”.

Cuối cùng, những lập luận được đề cập ở trên có thực sự là lý do chính đáng để không sử dụng ORM cho một ứng dụng doanh nghiệp dựa trên cơ sở dữ liệu không? Có lẽ có những lập luận khác mà họ / tôi có thể đã bỏ qua?

(Có lẽ tôi nên nói thêm rằng tôi nghĩ rằng đây giống như ứng dụng dựa trên .NET / C # “lớn” đầu tiên sẽ yêu cầu làm việc theo nhóm. Các phương pháp hay, được coi là khá bình thường trên Stack Overflow, chẳng hạn như kiểm tra đơn vị hoặc tích hợp liên tục, không - tồn tại ở đây cho đến nay.)

Đã có một sự bùng nổ tăng trưởng với ORM trong những năm gần đây và các đồng nghiệp giàu kinh nghiệm hơn của bạn có thể vẫn đang suy nghĩ "mọi cuộc gọi cơ sở dữ liệu phải thông qua một thủ tục được lưu trữ".

Tại sao ORM lại khiến mọi thứ khó gỡ lỗi hơn? Bạn sẽ nhận được cùng một kết quả cho dù nó đến từ một proc được lưu trữ hay từ ORM.

Tôi đoán điều thiệt hại thực sự duy nhất mà tôi có thể nghĩ đến với ORM là mô hình bảo mật kém linh hoạt hơn một chút.

CHỈNH SỬA: Tôi vừa đọc lại câu hỏi của bạn và có vẻ như họ đang sao chép và dán các truy vấn vào sql nội tuyến. Điều này làm cho mô hình bảo mật giống như một ORM, vì vậy sẽ không có lợi thế hoàn toàn về cách tiếp cận này so với ORM. Nếu họ đang sử dụng các truy vấn chưa được phân loại thì đó thực sự là một rủi ro bảo mật.

Câu trả lời ngắn gọn là có, có những lý do thực sự tốt. Thực tế là có những trường hợp bạn không thể sử dụng ORM.

Trường hợp cụ thể, tôi làm việc cho một tổ chức tài chính doanh nghiệp lớn và chúng tôi phải tuân theo rất nhiều hướng dẫn bảo mật. Để đáp ứng các quy tắc và quy định được đặt ra cho chúng tôi, cách duy nhất để vượt qua kiểm tra là duy trì quyền truy cập dữ liệu trong các quy trình được lưu trữ. Bây giờ một số có thể nói đó chỉ là điều ngu ngốc, nhưng thành thật mà nói thì không. Sử dụng công cụ ORM có nghĩa là công cụ / nhà phát triển có thể chèn, chọn, cập nhật hoặc xóa bất kỳ thứ gì họ muốn. Các thủ tục được lưu trữ cung cấp bảo mật cao hơn rất nhiều, đặc biệt là trong các môi trường khi xử lý dữ liệu máy khách. Tôi nghĩ rằng đây là lý do lớn nhất để xem xét. Bảo vệ.

Điểm hấp dẫn của ORMs

ORM hữu ích để tự động hóa hơn 95% truy vấn nếu chúng có thể áp dụng được. Điểm mạnh đặc biệt của chúng là ở chỗ bạn có một ứng dụng có kiến ​​trúc mô hình đối tượng mạnh mẽ và cơ sở dữ liệu phù hợp với mô hình đối tượng đó. Nếu bạn đang thực hiện một công trình mới và có kỹ năng lập mô hình vững chắc trong nhóm của mình thì bạn có thể sẽ nhận được kết quả tốt với ORM.

Bạn cũng có thể có một số truy vấn được thực hiện bằng tay tốt hơn. Trong trường hợp này, đừng ngại viết một vài thủ tục được lưu trữ để xử lý việc này. Ngay cả khi bạn định chuyển ứng dụng của mình trên nhiều nền tảng DBMS, mã phụ thuộc vào cơ sở dữ liệu sẽ chiếm thiểu số. Lưu ý rằng bạn sẽ cần phải kiểm tra ứng dụng của mình trên bất kỳ nền tảng nào mà bạn dự định hỗ trợ nó, một chút nỗ lực chuyển bổ sung cho một số quy trình được lưu trữ sẽ không tạo ra nhiều khác biệt cho TCO của bạn. Đối với ước tính đầu tiên, 98% di động cũng tốt như 100% di động và tốt hơn nhiều so với các giải pháp phức tạp hoặc hoạt động kém để hoạt động xung quanh giới hạn của ORM.

Tôi đã thấy cách tiếp cận trước đây hoạt động tốt trong một dự án J2EE rất lớn (100 năm nhân viên).

Trường hợp ORM có thể không phù hợp nhất

Trong các trường hợp khác, có thể có các cách tiếp cận phù hợp với ứng dụng hơn là ORM. Các mẫu Kiến trúc Ứng dụng Doanh nghiệp của Fowler có một phần về các mẫu truy cập dữ liệu thực hiện khá tốt việc lập danh mục các cách tiếp cận khác nhau cho vấn đề này. Một số ví dụ tôi đã thấy về các tình huống mà ORM có thể không áp dụng được là:

• Trên một ứng dụng có cơ sở mã kế thừa đáng kể của các thủ tục được lưu trữ, bạn có thể muốn sử dụng lớp truy cập dữ liệu theo hướng chức năng (không nên nhầm lẫn với ngôn ngữ chức năng) để bọc các mầm hiện tại. Điều này sử dụng lại lớp truy cập dữ liệu hiện có (và do đó đã được kiểm tra và gỡ lỗi) và thiết kế cơ sở dữ liệu, thường thể hiện nỗ lực phát triển và thử nghiệm khá đáng kể, đồng thời tiết kiệm được việc phải di chuyển dữ liệu sang một mô hình cơ sở dữ liệu mới. Nó thường là một cách khá tốt để gói các lớp Java xung quanh các cơ sở mã PL / SQL kế thừa, hoặc nhắm mục tiêu lại các ứng dụng khách hàng phong phú VB, Powerbuilder hoặc Delphi với giao diện web.

• Một biến thể là nơi bạn kế thừa một mô hình dữ liệu không nhất thiết phải phù hợp với ánh xạ HOẶC. Nếu (ví dụ) bạn đang viết một giao diện điền hoặc trích xuất dữ liệu từ một giao diện nước ngoài, bạn có thể tốt hơn nên làm việc trực tiếp với cơ sở dữ liệu.

• Các ứng dụng tài chính hoặc các loại hệ thống khác mà tính toàn vẹn của dữ liệu xuyên hệ thống là quan trọng, đặc biệt nếu bạn đang sử dụng các giao dịch phân tán phức tạp với cam kết hai giai đoạn. Bạn có thể cần phải quản lý vi mô các giao dịch của mình tốt hơn so với ORM có khả năng hỗ trợ.

• Các ứng dụng hiệu suất cao mà bạn muốn thực sự điều chỉnh quyền truy cập cơ sở dữ liệu của mình. Trong trường hợp này, có thể ưu tiên làm việc ở cấp độ thấp hơn.

• Các tình huống mà bạn đang sử dụng một cơ chế truy cập dữ liệu đương nhiệm như ADO.Net là 'đủ tốt' và chơi tốt với nền tảng này sẽ mang lại lợi ích lớn hơn ORM mang lại.

• Đôi khi dữ liệu chỉ là dữ liệu - có thể là trường hợp (ví dụ) ứng dụng của bạn đang làm việc với 'giao dịch' chứ không phải 'đối tượng' và đây là chế độ xem hợp lý của miền. Ví dụ về điều này có thể là một gói tài chính nơi bạn có các giao dịch với các trường phân tích có thể định cấu hình. Mặc dù bản thân ứng dụng có thể được xây dựng trên nền tảng OO, nó không bị ràng buộc với một mô hình miền doanh nghiệp duy nhất và có thể không nhận thức được nhiều hơn mã GL, tài khoản, loại tài liệu và nửa tá trường phân tích. Trong trường hợp này, ứng dụng không biết về mô hình miền nghiệp vụ như vậy và mô hình đối tượng (ngoài cấu trúc sổ cái) không liên quan đến ứng dụng.

Trước hết - việc sử dụng ORM sẽ không làm cho mã của bạn dễ kiểm tra hơn, cũng như nó sẽ không nhất thiết cung cấp bất kỳ lợi thế nào trong bối cảnh Tích hợp liên tục.

Theo kinh nghiệm của tôi, mặc dù việc sử dụng ORM có thể tăng tốc độ phát triển, nhưng vấn đề lớn nhất bạn cần giải quyết là:

1. Kiểm tra mã của bạn
2. Duy trì mã của bạn

Các giải pháp cho những điều này là:

1. Làm cho mã của bạn có thể kiểm tra được (sử dụng các nguyên tắc SOLID )
2. Viết các bài kiểm tra tự động cho càng nhiều mã càng tốt
3. Chạy các bài kiểm tra tự động thường xuyên nhất có thể

Đối với câu hỏi của bạn, hai phản đối mà bạn liệt kê có vẻ giống như sự thiếu hiểu biết hơn bất cứ điều gì khác.

Việc không thể viết các truy vấn SELECT bằng tay (mà theo tôi là lý do tại sao cần phải copy-paste) dường như cho thấy rằng có nhu cầu cấp bách về một số đào tạo SQL.

Có hai lý do tại sao tôi không sử dụng ORM:

1. Nó bị nghiêm cấm theo chính sách của công ty (trong trường hợp đó tôi sẽ đi làm ở một nơi khác)
2. Dự án cực kỳ chuyên sâu về dữ liệu và việc sử dụng các giải pháp cụ thể của nhà cung cấp (như BulkInsert) có ý nghĩa hơn.

Những lời từ chối thông thường về ORM (cụ thể là NHibernate) là:

1. Tốc độ

   Không có lý do gì tại sao việc sử dụng ORM lại chậm hơn so với Truy cập Dữ liệu được mã hóa thủ công. Trên thực tế, vì bộ nhớ đệm và tính năng tối ưu được tích hợp trong nó, nó có thể nhanh hơn. ORM tốt sẽ tạo ra một tập hợp các truy vấn có thể lặp lại mà bạn có thể tối ưu hóa lược đồ của mình. ORM tốt cũng sẽ cho phép truy xuất dữ liệu liên quan hiệu quả bằng cách sử dụng các chiến lược tìm nạp khác nhau.

2. Phức tạp

   Về độ phức tạp, sử dụng ORM có nghĩa là ít mã hơn, nói chung có nghĩa là ít phức tạp hơn. Nhiều người sử dụng quyền truy cập dữ liệu viết tay (hoặc mã được tạo) thấy mình đang viết khung của riêng họ qua các thư viện truy cập dữ liệu "cấp thấp" (như viết các phương thức trợ giúp cho ADO.Net). Những điều này tương đương với sự phức tạp hơn, và tệ hơn, chúng hiếm khi được ghi lại đầy đủ hoặc được kiểm tra tốt.
   Nếu bạn đang xem xét cụ thể về NHibernate, thì các công cụ như Fluent NHibernate và Linq To NHibernate cũng làm mềm đường cong học tập.

Điều khiến tôi quan tâm đến toàn bộ cuộc tranh luận về ORM là những người cho rằng sử dụng ORM sẽ quá khó / chậm / bất cứ điều gì cũng giống như những người hài lòng hơn khi sử dụng Linq To Sql hoặc Typed Datasets. Mặc dù Linq To Sql là một bước tiến lớn đi đúng hướng, nó vẫn còn chậm hơn nhiều năm ánh sáng so với một số ORM nguồn mở. Tuy nhiên, các khuôn khổ cho cả Tập dữ liệu đã nhập và cho Linq To Sql vẫn cực kỳ phức tạp và việc sử dụng chúng để đi quá xa (Bảng = Lớp) + (CRUD cơ bản) là một điều vô cùng khó khăn.

Lời khuyên của tôi là nếu, vào cuối ngày, bạn không thể nhận được ORM, thì hãy đảm bảo rằng quyền truy cập dữ liệu của bạn được tách biệt khỏi phần còn lại của mã và bạn làm theo lời khuyên của Gang Of Four về lập trình một giao diện. Ngoài ra, hãy tải một khung công tác Dependancy Injection để thực hiện việc nối dây.

(Làm thế nào đó cho một rant?)

Có rất nhiều vấn đề phổ biến mà các công cụ ORM như Hibernate là một công cụ thần thánh, và một số vấn đề lại là trở ngại. Tôi không biết đủ về dự án của bạn để biết nó là gì.

Một trong những điểm mạnh của Hibernate là bạn chỉ được nói mọi thứ 3 lần: mọi thuộc tính được đề cập trong lớp, tệp .hbm.xml và cơ sở dữ liệu. Với truy vấn SQL, các thuộc tính của bạn nằm trong lớp, cơ sở dữ liệu, câu lệnh select, câu lệnh chèn, câu lệnh cập nhật, câu lệnh xóa và tất cả mã sắp xếp và giải nén hỗ trợ các truy vấn SQL của bạn! Điều này có thể trở nên lộn xộn nhanh chóng. Mặt khác, bạn biết nó hoạt động như thế nào. Bạn có thể gỡ lỗi nó. Tất cả đều ở đó trong lớp bền bỉ của riêng bạn, không bị chôn vùi trong ruột của công cụ bên thứ ba.

Hibernate có thể là một đứa trẻ áp phích cho Định luật trừu tượng rò rỉ của Spolsky. Đi khỏi con đường bị đánh bại một chút và bạn cần biết hoạt động sâu bên trong của công cụ. Có thể rất khó chịu khi bạn biết rằng bạn có thể sửa lỗi SQL trong vài phút, nhưng thay vào đó bạn đang dành hàng giờ để cố gắng biến công cụ dang của mình tạo ra SQL hợp lý. Gỡ lỗi đôi khi là một cơn ác mộng, nhưng thật khó để thuyết phục những người chưa từng làm việc đó.

CHỈNH SỬA: Bạn có thể muốn xem xét iBatis.NET nếu họ không quay lại với NHibernate và họ muốn kiểm soát các truy vấn SQL của mình.

CHỈNH SỬA 2: Tuy nhiên, đây là lá cờ đỏ lớn: "Các phương pháp hay, được coi là khá bình thường trên Stack Overflow, chẳng hạn như thử nghiệm đơn vị hoặc tích hợp liên tục, cho đến nay vẫn chưa tồn tại ở đây." Vậy, những nhà phát triển "có kinh nghiệm" này, họ có kinh nghiệm gì trong việc phát triển? An ninh công việc của họ? Có vẻ như bạn có thể nằm trong số những người không đặc biệt quan tâm đến lĩnh vực này, vì vậy đừng để họ giết chết sự quan tâm của bạn. Bạn cần phải là người cân bằng. Bắt đầu trận đấu.

Tôi đã làm việc trong một dự án mà không sử dụng ORM rất thành công. Đó là một dự án

1. Phải có tỷ lệ theo chiều ngang ngay từ đầu
2. Phải được phát triển nhanh chóng
3. Có một mô hình miền tương đối đơn giản

Thời gian cần thiết để NHibernate hoạt động trong một cấu trúc được phân vùng theo chiều ngang sẽ lâu hơn nhiều so với thời gian để phát triển một bộ dữ liệu siêu đơn giản đã biết về sơ đồ phân vùng của chúng tôi ...

Vì vậy, trong 90% dự án mà tôi đã thực hiện trên ORM là một sự trợ giúp vô giá. Nhưng có một số trường hợp rất cụ thể mà tôi có thể thấy không sử dụng ORM là tốt nhất.

Trước tiên, hãy để tôi nói rằng ORM có thể giúp cuộc sống phát triển của bạn dễ dàng hơn nếu được tích hợp đúng cách, nhưng có một số vấn đề mà ORM thực sự có thể ngăn cản bạn đạt được các yêu cầu và mục tiêu đã nêu.

Tôi nhận thấy rằng khi thiết kế các hệ thống có yêu cầu cao về hiệu suất, tôi thường gặp khó khăn trong việc tìm cách làm cho hệ thống hoạt động hiệu quả hơn. Nhiều lần, tôi kết thúc với một giải pháp có cấu hình hiệu suất ghi nặng (nghĩa là chúng ta đang ghi dữ liệu nhiều hơn là đọc dữ liệu). Trong những trường hợp này, tôi muốn tận dụng các tiện ích mà nền tảng cơ sở dữ liệu cung cấp cho tôi để đạt được các mục tiêu về hiệu suất của chúng tôi (đó là OLTP, không phải OLAP). Vì vậy, nếu tôi đang sử dụng SQL Server và tôi biết tôi có rất nhiều dữ liệu để ghi, tại sao tôi không sử dụng chèn hàng loạt ... tốt, như bạn có thể đã phát hiện ra, hầu hết các ORMS (tôi không biết nếu thậm chí một cái không) không có khả năng tận dụng những lợi thế cụ thể của nền tảng như chèn số lượng lớn.

Bạn nên biết rằng bạn có thể kết hợp các kỹ thuật ORM và không phải ORM. Tôi vừa nhận thấy rằng có một số ít các trường hợp phức tạp mà ORM không thể hỗ trợ các yêu cầu của bạn và bạn phải giải quyết chúng cho những trường hợp đó.

Khi bạn cần cập nhật 50000000 bản ghi. Đặt một lá cờ hoặc bất cứ điều gì.

Hãy thử thực hiện việc này bằng ORM mà không cần gọi thủ tục được lưu trữ hoặc các lệnh SQL gốc ..

Cập nhật 1: Cũng thử truy xuất một bản ghi chỉ với một vài trường của nó. (Khi bạn có một bảng rất "rộng"). Hoặc một kết quả vô hướng. ORM cũng rất hấp dẫn.

CẬP NHẬT 2 : Có vẻ như EF 5.0 beta hứa hẹn cập nhật hàng loạt nhưng đây là tin rất nóng (2012, tháng 1)

Đối với một ứng dụng doanh nghiệp dựa trên cơ sở dữ liệu không tầm thường, thực sự không có gì biện minh cho việc không sử dụng ORM.

Các tính năng sang một bên:

• Bằng cách không sử dụng ORM, bạn đang giải quyết một vấn đề đã được giải quyết nhiều lần bởi các cộng đồng lớn hoặc các công ty có nguồn lực đáng kể.
• Bằng cách sử dụng ORM, phần cốt lõi của lớp truy cập dữ liệu của bạn được hưởng lợi từ những nỗ lực gỡ lỗi của cộng đồng hoặc công ty đó.

Để đưa ra một số quan điểm trong lập luận, hãy xem xét những lợi thế của việc sử dụng ADO.NET so với việc viết mã để tự phân tích luồng dữ liệu dạng bảng.

Tôi đã thấy sự thiếu hiểu biết về cách sử dụng ORM biện minh cho sự coi thường của nhà phát triển đối với ORM Ví dụ: háo hức tải (điều gì đó tôi nhận thấy bạn không đề cập đến). Hãy tưởng tượng bạn muốn truy xuất một khách hàng và tất cả các đơn đặt hàng của họ và tất cả các mục chi tiết đơn đặt hàng đó. Nếu bạn chỉ dựa vào tải chậm, bạn sẽ bỏ qua trải nghiệm ORM của mình với ý kiến: "ORM chậm". Nếu bạn học cách sử dụng tải háo hức, bạn sẽ thực hiện trong 2 phút với 5 dòng mã, những gì đồng nghiệp của bạn sẽ mất nửa ngày để thực hiện: một truy vấn tới cơ sở dữ liệu và liên kết kết quả với một hệ thống phân cấp các đối tượng. Một ví dụ khác sẽ là nỗi đau của việc viết thủ công các truy vấn SQL để thực hiện phân trang.

Ngoại lệ có thể có đối với việc sử dụng ORM sẽ là nếu ứng dụng đó là khung ORM được thiết kế để áp dụng các trừu tượng logic nghiệp vụ chuyên biệt và được thiết kế để sử dụng lại trên nhiều dự án. Tuy nhiên, ngay cả khi trường hợp đó xảy ra, bạn sẽ nhận được sự chấp nhận nhanh hơn bằng cách tăng cường ORM hiện có với những nội dung trừu tượng đó.

Đừng để kinh nghiệm của các thành viên cấp cao trong nhóm kéo bạn đi ngược hướng với sự phát triển của khoa học máy tính. Tôi đã phát triển chuyên nghiệp trong 23 năm, và một trong những nguyên nhân chính là sự coi thường cái mới của trường cũ. ORM là đối với SQL vì ngôn ngữ C là hợp ngữ và bạn có thể đặt cược rằng các ngôn ngữ tương đương với C ++ và C # đang trên đường đi của chúng. Một dòng của mã trường mới bằng 20 dòng của trường cũ.

Tôi nghĩ rằng có thể khi bạn làm việc trên các hệ thống lớn hơn, bạn có thể sử dụng công cụ tạo mã như CodeSmith thay vì ORM ... Gần đây tôi đã tìm thấy điều này: Khung hợp tác tạo ra các thủ tục được lưu trữ trên máy chủ SQL và cũng tạo ra các thực thể kinh doanh, người lập bản đồ, cổng, lazyload và tất cả những thứ đó trong C # ... hãy kiểm tra nó ... nó được viết bởi một nhóm ở đây ở Argentina ...

Tôi nghĩ rằng nó ở giữa mã hóa toàn bộ lớp truy cập dữ liệu và sử dụng ORM ...

Cá nhân tôi (cho đến gần đây) phản đối việc sử dụng ORM và đã từng sử dụng để viết một lớp truy cập dữ liệu đóng gói tất cả các lệnh SQL. Sự phản đối chính đối với ORM là tôi không tin tưởng việc triển khai ORM để viết chính xác SQL đúng. Và, đánh giá bằng các ORM mà tôi từng thấy (chủ yếu là các thư viện PHP), tôi nghĩ rằng tôi đã hoàn toàn đúng.

Bây giờ, hầu hết việc phát triển web của tôi đang sử dụng Django và tôi thấy ORM đi kèm thực sự tiện lợi và vì mô hình dữ liệu được thể hiện trước tiên trong các thuật ngữ của chúng và chỉ sau này trong SQL, nó hoạt động hoàn hảo cho nhu cầu của tôi. Tôi chắc rằng sẽ không quá khó để phát triển nó và cần bổ sung thêm SQL viết tay; nhưng đối với truy cập CRUD là quá đủ.

Tôi không biết về NHibernate; nhưng tôi đoán nó cũng "đủ tốt" cho hầu hết những gì bạn cần. Nhưng nếu các lập trình viên khác không tin tưởng nó; nó sẽ là nghi phạm chính đối với mọi lỗi liên quan đến dữ liệu, khiến việc xác minh trở nên tẻ nhạt hơn.

Bạn có thể cố gắng giới thiệu nó dần dần tại nơi làm việc của mình, trước tiên hãy tập trung vào các ứng dụng nhỏ 'hiển nhiên', như truy cập dữ liệu đơn giản. Sau một thời gian, nó có thể được sử dụng trên các nguyên mẫu và có thể không bị thay thế ...

Nếu đó là cơ sở dữ liệu OLAP (ví dụ: dữ liệu tĩnh, chỉ đọc được sử dụng để báo cáo / phân tích, v.v.) thì việc triển khai khung ORM là không phù hợp. Thay vào đó, sử dụng chức năng truy cập dữ liệu gốc của cơ sở dữ liệu chẳng hạn như các thủ tục được lưu trữ sẽ thích hợp hơn. ORM phù hợp hơn cho các hệ thống giao dịch (OLTP).

Tôi nghĩ rằng có nhiều lý do chính đáng để không sử dụng ORM. Trước hết, tôi là một nhà phát triển .NET và tôi muốn gắn bó với những gì mà khung công tác .NET tuyệt vời đã cung cấp cho tôi. Nó làm mọi thứ tôi có thể cần. Bằng cách làm này, bạn sẽ tiếp cận với một cách tiếp cận tiêu chuẩn hơn và do đó có nhiều cơ hội tốt hơn cho bất kỳ nhà phát triển nào khác đang làm việc trên cùng một dự án trên đường có thể chọn những gì ở đó và chạy với nó. Khả năng truy cập dữ liệu đã được cung cấp bởi Microsoft khá phong phú, không có lý do gì để loại bỏ chúng.

Tôi đã là một nhà phát triển chuyên nghiệp trong 10 năm, dẫn dắt nhiều dự án hàng triệu đô la rất thành công và tôi chưa bao giờ viết một ứng dụng cần thiết để có thể chuyển sang bất kỳ cơ sở dữ liệu nào. Tại sao bạn lại muốn khách hàng làm điều này? Lập kế hoạch cẩn thận, chọn cơ sở dữ liệu phù hợp cho những gì bạn cần và gắn bó với nó. Cá nhân SQL Server đã có thể làm bất cứ điều gì tôi cần làm. Thật dễ dàng và nó hoạt động tuyệt vời. Thậm chí còn có một phiên bản miễn phí hỗ trợ dữ liệu lên đến 10GB. Ồ, và nó hoạt động tuyệt vời với .NET.

Gần đây tôi đã phải bắt đầu làm việc trên một số dự án sử dụng ORM làm trình đo dữ liệu. Tôi nghĩ rằng nó không tốt, và một điều gì đó bổ sung mà tôi đã phải học cách sử dụng mà không có lý do gì. Trong trường hợp cực kỳ hiếm hoi mà khách hàng cần phải thay đổi cơ sở dữ liệu, tôi có thể dễ dàng làm lại toàn bộ trình trả dữ liệu trong thời gian ngắn hơn so với việc đánh lừa các nhà cung cấp ORM.

Thành thật mà nói, tôi nghĩ rằng có một công dụng thực sự cho ORM: Nếu bạn đang xây dựng một ứng dụng như SAP thực sự cần khả năng chạy trên nhiều cơ sở dữ liệu. Nếu không, với tư cách là nhà cung cấp giải pháp, tôi nói với khách hàng của mình rằng ứng dụng này được thiết kế để chạy trên cơ sở dữ liệu này và đó là cách nó hoạt động. Một lần nữa, sau 10 năm và vô số ứng dụng, điều này chưa bao giờ là một vấn đề.

Nếu không, tôi nghĩ ORM dành cho những nhà phát triển không hiểu càng nhiều càng tốt và nghĩ rằng họ càng sử dụng nhiều công cụ của bên thứ 3 trong ứng dụng của mình thì ứng dụng của họ càng tốt. Tôi sẽ để những thứ như thế này cho những chuyên viên uber khó tính trong khi tôi tạo ra nhiều phần mềm tuyệt vời hơn trong thời gian chờ đợi mà bất kỳ nhà phát triển nào cũng có thể chọn và ngay lập tức làm việc hiệu quả.

Hiệu suất thời gian chạy là nhược điểm thực sự duy nhất mà tôi có thể nghĩ đến nhưng tôi nghĩ đó còn hơn cả một sự đánh đổi công bằng cho thời gian ORM giúp bạn phát triển / thử nghiệm / v.v. Và trong hầu hết các trường hợp, bạn có thể xác định vị trí tắc nghẽn dữ liệu và thay đổi cấu trúc đối tượng của mình để hiệu quả hơn.

Tôi chưa sử dụng Hibernate trước đây nhưng có một điều tôi nhận thấy với một số giải pháp ORM "không có sẵn" là thiếu tính linh hoạt. Tôi chắc chắn rằng điều này phụ thuộc vào việc bạn sử dụng cái nào và bạn cần làm gì với nó.

Có hai khía cạnh của ORM đáng lo ngại. Đầu tiên, chúng là mã do người khác viết, đôi khi là mã nguồn đóng, đôi khi là mã nguồn mở nhưng phạm vi rất lớn. Thứ hai, họ sao chép dữ liệu.

Vấn đề đầu tiên gây ra hai vấn đề. Bạn đang dựa vào mã bên ngoài. Tất cả chúng ta đều làm điều này, nhưng không nên xem nhẹ sự lựa chọn để làm như vậy. Và điều gì sẽ xảy ra nếu nó không làm những gì bạn cần? Khi nào bạn sẽ phát hiện ra điều này? Bạn sống bên trong hộp mà ORM của bạn vẽ cho bạn.

Vấn đề thứ hai là một trong hai giai đoạn cam kết. Cơ sở dữ liệu quan hệ đang được sao chép vào một mô hình đối tượng. Bạn thay đổi mô hình đối tượng và nó phải cập nhật cơ sở dữ liệu. Đây là một cam kết hai giai đoạn và không phải là điều dễ dàng nhất để gỡ lỗi.

Tôi khuyên bạn nên đọc bài này để biết danh sách các nhược điểm của ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Đối với bản thân tôi, tôi thấy ORM rất hữu ích cho hầu hết các ứng dụng tôi đã viết!

/ Asger

Kinh nghiệm mà tôi đã có với Hibernate là ngữ nghĩa của nó rất tinh tế, và khi có vấn đề, sẽ hơi khó hiểu chuyện gì đang xảy ra. Tôi đã nghe từ một người bạn rằng một người thường bắt đầu với Criteria, sau đó cần linh hoạt hơn một chút và cần HQL, và sau đó nhận thấy rằng sau cùng, cần có SQL thô (ví dụ: Hibernate không có union AFAIK).

Cũng với ORM, mọi người dễ dàng có xu hướng lạm dụng các ánh xạ / mô hình hiện có, dẫn đến việc có một đối tượng có nhiều thuộc tính không được khởi tạo. Vì vậy, sau khi truy vấn, bên trong giao dịch Hibernate thực hiện tìm nạp dữ liệu bổ sung, dẫn đến khả năng làm chậm. Cũng đáng buồn thay, đối tượng mô hình ngủ đông đôi khi bị rò rỉ vào lớp kiến ​​trúc chế độ xem và sau đó chúng ta thấy LazyInitializationExceptions.

Để sử dụng ORM, người ta phải thực sự hiểu nó. Thật không may, người ta dễ dàng ấn tượng rằng nó dễ dàng trong khi nó không.

Không phải là một câu trả lời cho riêng mình, tôi muốn diễn đạt lại một câu trích dẫn mà tôi đã nghe gần đây. "ORM tốt cũng giống như Yeti, mọi người nói về một người nhưng không ai nhìn thấy nó."

Bất cứ khi nào tôi đặt tay vào một ORM, tôi thường thấy mình phải vật lộn với các vấn đề / hạn chế của ORM đó. Cuối cùng, vâng nó làm những gì tôi muốn và nó đã được viết ở đâu đó trong tài liệu tệ hại đó nhưng tôi thấy mình mất thêm một giờ nữa mà tôi sẽ không bao giờ có được. Bất cứ ai đã sử dụng nhibernate, sau đó thông thạo nhibernate trên postgresql sẽ hiểu những gì tôi đã trải qua. Cảm giác liên tục "mã này không nằm trong tầm kiểm soát của tôi" thực sự rất tệ.

Tôi không chỉ tay hay nói rằng chúng xấu, nhưng tôi bắt đầu nghĩ về những gì tôi đang cho đi chỉ để tự động hóa CRUD trong một biểu thức duy nhất. Ngày nay, tôi nghĩ tôi nên sử dụng ORM ít hơn, có thể tạo hoặc tìm một giải pháp cho phép hoạt động db ở mức tối thiểu. Nhưng đó chỉ là tôi. Tôi tin rằng có một số điều không ổn trong đấu trường ORM này nhưng tôi không đủ kỹ năng để thể hiện điều đó.

Tôi nghĩ rằng sử dụng ORM vẫn là một ý kiến ​​hay. Đặc biệt là xem xét tình huống bạn đưa ra. Có vẻ như qua bài viết của bạn, bạn là người có kinh nghiệm hơn khi nói đến các chiến lược truy cập db và tôi sẽ giới thiệu bằng cách sử dụng ORM.

Không có lập luận nào cho # 1 vì sao chép và dán các truy vấn và mã cứng trong văn bản không có tính linh hoạt và đối với # 2 hầu hết các tổ chức sẽ bao gồm ngoại lệ ban đầu, sẽ cho phép truy tìm các truy vấn được tạo, v.v., vì vậy việc gỡ lỗi cũng không phải là khoa học tên lửa.

Đối với xác thực, việc sử dụng ORM thường sẽ cho phép thời gian dễ dàng hơn nhiều khi phát triển các chiến lược xác thực, trên bất kỳ xác thực nào được xây dựng sẵn.

Viết khuôn khổ của riêng bạn có thể tốn công sức và thường mọi thứ bị bỏ sót.

EDIT: Tôi muốn làm cho một điểm nữa. Nếu công ty của bạn áp dụng chiến lược ORM, chiến lược đó sẽ nâng cao hơn nữa giá trị của nó, vì bạn sẽ phát triển các hướng dẫn và thực hành để sử dụng và triển khai và mọi người sẽ nâng cao hơn nữa kiến ​​thức của họ về khuôn khổ đã chọn, giảm thiểu một trong những vấn đề bạn đã đưa ra. Ngoài ra, bạn sẽ học được điều gì hiệu quả và điều gì không hiệu quả khi tình huống phát sinh, và cuối cùng, nó sẽ tiết kiệm rất nhiều thời gian và công sức.

Mỗi ORM, thậm chí là "tốt", đều đi kèm với một số giả định nhất định liên quan đến cơ chế cơ bản mà phần mềm sử dụng để chuyển dữ liệu qua lại giữa lớp ứng dụng và kho dữ liệu của bạn.

Tôi nhận thấy rằng đối với ứng dụng phức tạp vừa phải, việc giải quyết các giả định đó thường khiến tôi mất nhiều thời gian hơn là chỉ viết một giải pháp đơn giản hơn như: truy vấn dữ liệu và khởi tạo các thực thể mới theo cách thủ công.

Đặc biệt, bạn có thể gặp khó khăn ngay khi sử dụng các khóa nhiều cột hoặc các mối quan hệ vừa phải phức tạp khác nằm ngoài phạm vi của các ví dụ hữu ích mà ORM đã cung cấp cho bạn khi bạn tải xuống mã.

Tôi thừa nhận rằng đối với một số loại ứng dụng nhất định, đặc biệt là những ứng dụng có số lượng bảng cơ sở dữ liệu rất lớn hoặc bảng cơ sở dữ liệu được tạo động, quy trình tự động ma thuật của ORM có thể hữu ích.

Nếu không, chết tiệt với ORM. Bây giờ tôi coi chúng về cơ bản là một thứ mốt nhất thời.