Các tiêu chí để đánh giá ORM for.NET là gì? [đóng cửa]

Tôi đang xem xét đánh giá các ORM.

Tôi đã sử dụng SubSonic , Linq-to-SQL và Entity Framework . Tôi đã có một nhóm các nhà phát triển từ đàn em đến đàn anh.

Các tiêu chí để đánh giá ORM for.NET là gì?

Đó là một câu hỏi được tải.
Có rất nhiều ORM rất giỏi tiếp cận chủ đề với những triết lý khác nhau.
Không có gì là hoàn hảo và tất cả đều có xu hướng trở nên phức tạp ngay khi bạn đi lạc khỏi con đường vàng của họ (và đôi khi ngay cả khi bạn dính vào nó).

Những gì bạn nên tự hỏi khi chọn một ORM:

1. Nó cần làm gì cho bạn?
   Nếu bạn đã có một bộ các yêu cầu cho ứng dụng của mình, thì bạn nên chọn ORM phù hợp hơn với các yêu cầu này thay vì một giả thuyết 'tốt nhất'.

2. Dữ liệu của bạn được chia sẻ hay chỉ là cục bộ?
   Rất nhiều sự xáo trộn trong ORM là do cách họ xử lý đồng thời và thay đổi dữ liệu trong cơ sở dữ liệu khi nhiều người dùng đang giữ một phiên bản của cùng một dữ liệu.
   Nếu kho dữ liệu của bạn dành cho một người dùng, thì hầu hết các ORM sẽ làm tốt công việc. Tuy nhiên, hãy tự hỏi mình một số câu hỏi khó trong kịch bản nhiều người dùng: khóa được xử lý như thế nào? Điều gì xảy ra khi tôi xóa một đối tượng? Nó ảnh hưởng đến các đối tượng liên quan khác như thế nào? Là ORM hoạt động gần với kim loại của phụ trợ hay nó lưu trữ rất nhiều dữ liệu (cải thiện hiệu suất với chi phí làm tăng nguy cơ bị cứng).

3. ORM có thích nghi tốt với loại ứng dụng của bạn không? Một ORM cụ thể có thể khó hoạt động (nhiều chi phí hiệu năng, khó mã hóa) nếu nó được sử dụng trong dịch vụ hoặc ngồi trong ứng dụng web. Nó có thể trái lại là tuyệt vời cho các ứng dụng máy tính để bàn.

4. Bạn có phải từ bỏ các cải tiến dành riêng cho cơ sở dữ liệu?
   Các ORM có xu hướng sử dụng bộ mẫu số chung thấp nhất của SQL để đảm bảo chúng hoạt động với nhiều phụ trợ cơ sở dữ liệu khác nhau.
   Tất cả các ORM sẽ thỏa hiệp trên các tính năng khả dụng (trừ khi chúng nhắm mục tiêu cụ thể vào một phụ trợ duy nhất) nhưng một số sẽ cho phép bạn thực hiện các hành vi bổ sung để khai thác các cải tiến cụ thể có sẵn trong phụ trợ đã chọn của bạn.
   Ví dụ, một cải tiến dành riêng cho db cụ thể là các khả năng tìm kiếm Toàn văn; đảm bảo ORM của bạn cung cấp cho bạn cách truy cập các tính năng này nếu bạn cần chúng.

5. Làm thế nào để ORM quản lý các thay đổi trong mô hình dữ liệu?
   Một số có thể tự động cập nhật DB theo một biện pháp nhất định, những người khác không làm gì cả và bạn sẽ phải tự mình làm công việc bẩn thỉu; khác cung cấp một khung để xử lý thay đổi cho phép bạn kiểm soát các cập nhật cơ sở dữ liệu.

6. Bạn có ý định ghép đôi ứng dụng của mình với các đối tượng của ORM hay bạn thích xử lý POCO và sử dụng bộ điều hợp để duy trì?
   Cái trước thường đơn giản để xử lý nhưng tạo ra sự phụ thuộc vào các đối tượng dữ liệu cụ thể ORM của bạn ở mọi nơi, cái sau linh hoạt hơn, với chi phí của một mã nhiều hơn một chút.

7. Bạn sẽ bao giờ cần phải chuyển đối tượng của bạn từ xa?
   Không phải tất cả các ORM đều như nhau khi tìm nạp các đối tượng từ một máy chủ từ xa, hãy xem xét kỹ những gì có thể hoặc không thể làm được. Một số là hiệu quả, những người khác thì không.

8. Có ai đó bạn có thể nhờ giúp đỡ?
   Có hỗ trợ thương mại tốt? Làm thế nào lớn và tích cực là cộng đồng xung quanh dự án?
   Những vấn đề người dùng hiện đang gặp phải với sản phẩm là gì?
   Họ có nhận được giải pháp nhanh chóng?

Một vài ORM mà tôi đã xem:

• XPO
  Từ nhà phát triển Express: nhỏ và đơn giản, lấy mã làm trung tâm. Họ sử dụng nó cho khung ứng dụng eXpressApp của họ .
• NHibernate
  Miễn phí, nhưng đường cong học tập khá dốc. Rất nhiều điều tốt đẹp nhưng thật khó để tìm thấy những gì thực sự có liên quan đôi khi trong tất cả các tài liệu phân mảnh.
• LLBLGen Pro
  dự án rất trưởng thành, không đơn giản nhất nhưng rất nhiều suy nghĩ đã được đặt vào nó.
• Thực thể khung
  GEtting đó. Các bản phát hành cuối cùng khá tốt và MS đang lắng nghe, mặc dù nó vẫn còn hơi trẻ so với các ORM trưởng thành hơn khác.
• DataObject.Net
  Có vẻ đầy hứa hẹn nhưng cũng hơi mới để mạo hiểm với một dự án quan trọng trên nó IMHO. Khá hoạt động mặc dù.

Có nhiều người khác tất nhiên.

Bạn có thể xem trang ORM Battle gây tranh cãi liệt kê một số điểm chuẩn hiệu suất, mặc dù bạn phải biết rằng tốc độ thô không nhất thiết là yếu tố quan trọng nhất cho dự án của bạn và nhà sản xuất trang web là DataObject.Net.

Tôi đang sử dụng NHibernate và thấy nó khá tốt.

Trong trường hợp của tôi, được liên kết với cơ sở dữ liệu MS Sql, nhưng bạn có thể kết nối với các cơ sở dữ liệu khác.

Không mất nhiều thời gian để khởi động và chạy - chỉ cần ánh xạ đối tượng của bạn vào mô hình - Tôi sử dụng tệp xml nhưng bạn có thể thực hiện thành thạo mã. Có một cộng đồng tuyệt vời và cá nhân tôi thấy công việc của Ayende rất hữu ích - tôi sử dụng NHProf, một công cụ định hình sql.

Tôi chủ yếu sử dụng các hàm ngoài hộp - ánh xạ đối tượng thẳng, nhưng tôi cũng sử dụng Ngôn ngữ truy vấn Hibernate, khá dễ để nắm bắt.

Đáng buồn thay, trong ba công việc cuối cùng của tôi, chúng tôi đã có ba ORM tự trồng tại nhà. Trong mỗi trường hợp, họ chủ yếu hút vì những lý do khác nhau.

Gần đây tôi đã đánh giá Entity Framework 4 và hỗ trợ POCO của nó (một hướng dẫn tốt đẹp ở đây ) và tôi thực sự ấn tượng về cách nó nằm ngoài khuôn mặt của tôi và khiến tôi cảm thấy như mình đang lập trình lại thay vì dữ liệu.

So sánh và điểm chuẩn ORM trên ORMBattle.NET

Tôi thích Linq đến Sql rất nhiều. Nó đơn giản và có một nhà thiết kế phong nha. Tuy nhiên, tôi hy vọng sẽ kết thúc cuộc sống theo hướng có lợi cho khung Entity. Tôi muốn có khả năng tận dụng khả năng sửa đổi các trình tạo để tôi có thể có các đối tượng tùy chỉnh.

Lợi ích lớn nhất mà những thứ này mang lại cho người khác (theo ý kiến ​​của tôi) là chúng nằm ngoài khả năng của VS. Đây cũng là một tiêu cực ở chỗ bạn đang thương xót MS (xem Linq to Sql).

[TUYÊN BỐ TỪ CHỐI: Tôi làm việc cho DevExpress]

Bạn có thể xem ảnh chụp màn hình của các ứng dụng điển hình được tạo bởi các khung ứng dụng DevExpress tại đây . Trang này cũng chứa một đánh giá rất ngắn gọn về các sản phẩm của chúng tôi. Để biết thêm thông tin chi tiết về lý do , tôi khuyên bạn nên xem các trang sản phẩm tương ứng trên trang web của chúng tôi.

Đối với DevExpress XAF và XPO, đây là một lời giải thích tốt về lý do tại sao chọn các khung ứng dụng của chúng tôi. Thêm vào đó, chúng tôi cung cấp hỗ trợ và tài liệu, đó cũng là điều quan trọng và đáng nói. Hãy liên hệ với chúng tôi trong trường hợp có bất kỳ câu hỏi.

Chúng tôi sử dụng NHibernate + Fluent NHibernate, với Linq-to-Sql cho các dự án nhỏ. Lý giải cho vấn đề này là:

1) (Không phải lý do chính) NHibernate dường như có yếu tố "tôn trọng" cao hơn giữa các nhà phát triển (điều này có đúng không?),

2) So với linq-to-SQL, nHibernate cho phép ánh xạ ORM giữa các đối tượng Db và các thực thể không ánh xạ 1 đến 1,

3) Chúng tôi chưa so sánh rộng rãi nHibernate với Entity Framework 4.0 nhưng đây là một so sánh tốt: http://ayende.com/blog/archive/2010/01/05/nhibernate-vs.-entity-framework-4.0.aspx

nHibernate có phần nào của một đường cong học tập dốc và bản đồ XML của nó có thể khá dài dòng, nhưng hãy bắt đầu với tài liệu trang web Fluent Nhibernate và làm việc theo cách của bạn.

Không có khung ORM "tốt nhất" bởi vì tất cả chúng đều có các kết hợp điểm mạnh và điểm yếu khác nhau và có xu hướng là nếu các nhà phát triển chọn tập trung vào việc làm cho một khu vực tốt hơn thì có những khu vực khác bị so sánh (mã đầu tiên so với mô hình đầu tiên so với cơ sở dữ liệu đầu tiên).

Mặt khác, có một số trong số đó rất tốt, một số trong đó sẽ phù hợp hơn với hoàn cảnh và triết lý cá nhân của bạn so với những người khác.

Chỉnh sửa: Với giá trị của nó, tôi hiện đang sử dụng Linq cho SQL - chủ yếu là vì nó có một phần vì nó rất phù hợp với nỗ lực tối thiểu và có thể sẽ tiến tới Entity Framework một lần nữa "vì nó cũng vậy" (mặc dù tương tự cũng có rất nhiều điều về EF4 đúng cũng như một số thứ sai). Mối quan tâm, đặc biệt với cái sau, sẽ phải là hiệu năng nhưng đối với hầu hết các trường hợp của tôi, đó không phải là vấn đề lớn và khả năng chạy Dữ liệu động và OData từ các mô hình (L2S và EF) có lợi ích đáng kể cho tôi về " giá rẻ "chiến thắng.

Tôi khuyên bạn nên xem DevExpress XPO . Điều này cùng với DevExpress XAF sẽ giúp cuộc sống của bất kỳ nhà phát triển nào trở nên dễ dàng một khi đường cong học tập của nó bị vượt qua.

Chúng tôi đã có may mắn với Entity Framework. Tuy nhiên, tình huống của chúng tôi hơi bất thường - chúng tôi thực hiện thu thập dữ liệu cho nhóm báo cáo, vì vậy họ thực sự thiết kế cơ sở dữ liệu. Chúng tôi nhận được DB và sau đó chỉ cần sử dụng EF để tạo các lớp truy cập dữ liệu từ nó. Hoạt động tốt cho chúng tôi, nhưng chúng tôi chỉ tải dữ liệu số lượng lớn, vì vậy tôi không thể đảm bảo nó hoạt động tốt như thế nào trong môi trường giao dịch nhiều hơn.

NHibernate (+ FluentNHibernate) sẽ là tùy chọn mặc định cho tôi. Nó rất linh hoạt, mở rộng và mạnh mẽ. Nó có một lượng lớn người dùng và nó được duy trì rất tích cực. Nhược điểm là đường cong học tập dốc.

LightSpeed ​​của MindScape đơn giản và thân thiện với người dùng, nhưng vẫn khá linh hoạt và có khả năng. Nó có bề mặt thiết kế như L2S / EF và triển khai UnitOfWork.

Chà, không có lựa chọn "tốt nhất" nào nhưng tôi muốn nói rằng Linq cũ đối với SQL thường xuyên đáp ứng nhu cầu của bạn. Nó không phải là ORM "thật" mỗi se, nhưng nó rất nhẹ và cho phép bạn linh hoạt viết mã mà không nhận thức được điều đó, nếu điều đó có ý nghĩa. Ý tôi là bạn có thể tiếp tục viết mã như bình thường mà không cần phải thực sự biết về Linq ngoài việc có dbml(các) tệp. Bạn vẫn có thể viết các tóm tắt trên nó, bằng cách sử dụng các mẫu Kho lưu trữ hoặc Cổng và L2S hoàn thành vai trò chính của ORM, đó là để giải quyết vấn đề Không khớp quan hệ đối tượng.

Entity Framework hơi nặng nề và trong khi tôi chỉ hiểu một chút về nó thì "trong khuôn mặt của bạn" nhiều hơn so với Linq cơ bản đối với Sql, nhưng EF là một ORM thực sự hơn nhiều so với Linq. Tôi sẽ xem xét tất cả các tiêu chí bạn đang tìm kiếm trong một ORM. Có phải chỉ vì bạn muốn tránh phải viết SQL thô hoặc tệ hơn là có hàng trăm Thủ tục được lưu trữ? Bạn có cần một số tính năng bổ sung mà Linq thô cho Sql không thể cung cấp không? Bạn cần trả lời những câu hỏi đó, nhưng dựa trên yêu cầu ngắn gọn của bạn ("nhẹ và dễ sử dụng") Tôi nghĩ Linq dễ hơn một chút so với Subsonic và được tích hợp trong Visual Studio.

ECO :) Nó không chỉ là một ORM trong khi bao gồm các máy trạng thái và hỗ trợ OCL (cụ thể là EAL). Có một phiên bản miễn phí với giới hạn 12 lớp miền mà tôi nghĩ là khá gọn gàng cho các dự án nhỏ.