O/R Người lập bản đồ - Tốt hay xấu

Question

Tôi thực sự bị rách ngay giữa việc sử dụng trình lập bản đồ O/R hoặc chỉ gắn bó với truy cập dữ liệu truyền thống. Vì một lý do nào đó, mỗi khi tôi đưa ra những người lập bản đồ O/R, các nhà phát triển đồng nghiệp rụt rè và nói về các vấn đề về hiệu suất hoặc cách chúng chỉ xấu nói chung. Tôi đang thiếu gì ở đây? Tôi đang xem LINQ to SQL và Microsoft Entity Framework. Có bất kỳ cơ sở nào cho bất kỳ khiếu nại nào trong số này không? Tôi phải thỏa hiệp gì nếu tôi muốn sử dụng một người lập bản đồ O/R. Cảm ơn.

Answer 1

Vấn đề mà tôi thấy với rất nhiều OR ánh xạ là bạn nhận được các đối tượng miền cồng kềnh, thường được kết hợp với phần còn lại của khung truy cập dữ liệu của bạn. Các nhà phát triển của chúng tôi cũng đang níu kéo điều đó :) Thật khó để chuyển các đối tượng này sang một công nghệ truy cập dữ liệu khác. Nếu bạn sử dụng L2S, bạn có thể xem mã được tạo. Nó trông giống như một mớ hỗn độn hoàn toàn. NHibernate có lẽ là một trong những tốt nhất ở đây. Các thực thể của bạn hoàn toàn không biết về lớp truy cập dữ liệu của bạn, nếu bạn thiết kế chúng đúng.

Answer 2

Lần đầu tiên tôi vào bản đồ ORM và Lớp truy cập dữ liệu từ đọc sách của Rockford Lhotka, các đối tượng kinh doanh C#. Ông đã dành nhiều năm làm việc trên một khuôn khổ cho DAL. Trong khi khuôn khổ của ông ra khỏi hộp là khá cồng kềnh và trong một số trường hợp, quá mức cần thiết, ông có một số ý tưởng tuyệt vời. Tôi đánh giá cao cuốn sách này cho bất kỳ ai đang xem bản đồ ORM. Tôi đã bị ảnh hưởng bởi cuốn sách của ông, đủ để lấy đi rất nhiều ý tưởng của ông và xây dựng chúng thành khung của riêng tôi và tạo mã.

Answer 3

Điều này có vẻ như một câu trả lời không liên quan lúc đầu, nhưng: một trong những lợi ích của tôi là máy bay chiến đấu thời kỳ Thế chiến II. Tất cả các quốc gia chiến đấu (Mỹ, Anh, Đức, Liên Xô, Nhật Bản, vv) đã xây dựng một loạt các chiến binh khác nhau trong chiến tranh. Một số người trong số họ sử dụng động cơ xuyên tâm (P47, Corsair, FW-190, Zero); một số động cơ được làm mát bằng chất lỏng bên trong (Bf-109, Mustang, Yak-7, Spitfire); và một số sử dụng hai động cơ thay vì một (P38, Do-335). Một số súng máy đã qua sử dụng, một số khẩu pháo đã qua sử dụng và một số được sử dụng cả hai. Một số thậm chí còn được làm từ gỗ dán, nếu bạn có thể tưởng tượng.

Cuối cùng, tất cả đều thực sự thực sự nhanh chóng, và trong tay một phi công có kinh nghiệm, có kinh nghiệm, họ sẽ bắn rookie tân binh của bạn xuống trong một nhịp tim. Tôi không tưởng tượng nhiều phi công bay xung quanh nghĩ rằng "Ôi, tên ngốc đó đang bay thứ gì đó với một động cơ hướng tâm - tôi không phải lo lắng về anh ấy chút nào". Mọi người đều hiểu rằng có nhiều cách khác nhau để đạt được mục tiêu cuối cùng, và mỗi cách tiếp cận đều có những ưu điểm và nhược điểm riêng, tùy thuộc vào hoàn cảnh.

Cuộc tranh luận giữa ORM và truy cập dữ liệu truyền thống giống như thế này, và nó xử lý bất kỳ lập trình viên nào có thẩm quyền với cả hai cách tiếp cận và chọn tùy chọn phù hợp với công việc trong tầm tay.

Answer 4

Tôi đã đấu tranh với quyết định này trong một thời gian dài. Tôi nghĩ rằng tôi đã do dự vì hai lý do chính. Đầu tiên, những người vẽ bản đồ O/R thể hiện sự thiếu kiểm soát những gì đang xảy ra trong một phần quan trọng của ứng dụng và, thứ hai, bởi vì rất nhiều lần tôi thất vọng bởi các giải pháp tuyệt vời cho trường hợp 90% nhưng đáng khinh 10%. Tất cả mọi thứ hoạt động cho chọn * từ các tác giả, tất nhiên, nhưng khi bạn khuấy động sự phức tạp và có hệ thống quan trọng, khối lượng lớn và sự nghiệp của bạn là trên đường, bạn cảm thấy cần phải có toàn quyền điều chỉnh mọi mẫu truy vấn và byte qua dây. Hầu hết các nhà phát triển, bao gồm cả tôi, bị thất vọng lần đầu tiên công cụ thất bại, và chúng tôi không thể làm những gì chúng tôi cần làm, hoặc nhu cầu của chúng tôi lệch khỏi mô hình được hỗ trợ bởi công cụ. Có lẽ tôi sẽ bị dập tắt vì đề cập đến những lỗi cụ thể trong các công cụ, vì vậy tôi sẽ để nó ở đó.

May mắn thay, Anderson Imes cuối cùng đã thuyết phục tôi thử CodeSmith với số netTiers template. (Không, tôi không làm việc cho họ.) Sau hơn một năm sử dụng, tôi không thể tin rằng chúng tôi đã không làm điều đó sớm hơn. Nhóm của tôi sử dụng Visual Studio DB Pro và mỗi khi đăng ký, trình xây dựng tích hợp liên tục của chúng tôi sẽ loại bỏ một tập hợp các lớp truy cập dữ liệu mới.Điều này xử lý tất cả các công cụ phổ biến, rủi ro thấp một cách tự động, nhưng chúng ta vẫn có thể viết sprocs tùy chỉnh cho các bit phức tạp và đưa chúng vào như các phương thức trên các lớp đã tạo và chúng ta cũng có thể tùy chỉnh các mẫu cho mã được tạo ra. Tôi rất khuyên bạn nên tiếp cận này. Có thể có các công cụ khác cho phép mức kiểm soát này, và có một mẫu CodeSmith mới hơn được gọi là PLINQO sử dụng LINQ to SQL dưới mui xe. Chúng tôi vẫn chưa kiểm tra (không cần thiết), nhưng cách tiếp cận tổng thể này có rất nhiều công đức.

Jerry

Answer 5

Không có câu trả lời đơn giản nào vì mỗi nhà cung cấp ORM sẽ có ưu điểm và nhược điểm riêng. Một số giải pháp ORM linh hoạt hơn các giải pháp khác. Các onus là trên các nhà phát triển để hiểu những điều này trước khi sử dụng một.

Tuy nhiên, hãy LinqToSql - nếu bạn chắc chắn bạn sẽ không cần phải chuyển đổi khỏi SQL Server thì điều này giải quyết rất nhiều vấn đề phổ biến được thấy trong trình ánh xạ ORM. Nó cho phép bạn dễ dàng thêm các thủ tục được lưu trữ (như các phương thức tĩnh), vì vậy bạn không chỉ bị giới hạn trong SQL được tạo ra. Nó sử dụng thực thi trì hoãn, để bạn có thể kết nối các truy vấn một cách hiệu quả. Nó sử dụng các lớp một phần để cho phép bạn dễ dàng thêm logic tùy chỉnh vào các lớp được tạo mà không cần phải lo lắng về những gì sẽ xảy ra khi bạn tạo lại chúng. Cũng không có gì ngăn cản bạn sử dụng LINQ để tạo DAL của riêng bạn, trừu tượng hóa - nó chỉ tăng tốc quá trình. Điều chính, điều, mặc dù là nó làm giảm bớt tedium và thời gian cần thiết để tạo ra lớp CRUD cơ bản.

Nhưng cũng có những nhược điểm. Sẽ có một sự kết hợp chặt chẽ giữa các bảng và các lớp học của bạn, sẽ có hiệu suất giảm nhẹ, đôi khi bạn có thể tạo các truy vấn không hiệu quả như bạn mong đợi. Và bạn được gắn vào SQL Server (mặc dù một số kỹ thuật ORM khác là cơ sở dữ liệu bất khả tri).

Như tôi đã nói, điều chính là phải nhận thức được ưu và nhược điểm trước khi ghim màu của bạn vào một phương pháp cụ thể.

Answer 6

Công cụ O/RM được thiết kế để hoạt động rất tốt trong hầu hết các trường hợp. Nó sẽ cache các thực thể cho bạn, nó sẽ thực thi truy vấn trong bulks, nó có mức truy cập tối ưu rất thấp đối với các đối tượng nhanh hơn việc gán giá trị cho thuộc tính một cách thủ công, chúng cung cấp cho bạn một cách rất dễ dàng để kết hợp các biến thể của lập trình hướng khía cạnh sử dụng kỹ thuật hiện đại như kẻ đánh chặn, nó sẽ quản lý nhà nước thực thể cho bạn và giúp giải quyết xung đột và nhiều hơn nữa.

Giờ đây, nhược điểm của phương pháp này thường nằm ở sự thiếu hiểu biết về cách mọi thứ hoạt động ở mức rất thấp. Vấn đề cổ điển nhất là "SELECT N + 1" (link).

Tôi đã làm việc với NHibernate trong 2,5 năm nay và tôi vẫn đang khám phá một điều gì đó mới mẻ về nó hàng ngày ...

Answer 7

Tốt. Trong hầu hết các trường hợp.

Lợi ích về năng suất của việc sử dụng ORM, trong hầu hết trường hợp, sẽ vượt quá sự mất kiểm soát đối với cách truy cập dữ liệu.

Không có nhiều người sẽ tránh C#, để chương trình là MSIL hoặc hội, mặc dù điều đó sẽ giúp họ kiểm soát nhiều hơn.

Answer 8

Nó thực sự phụ thuộc vào tình huống.

Tôi đã đi từ một công ty đã sử dụng ORM được tinh chỉnh cho một công ty không sử dụng ORM và đã viết truy vấn SQL mọi lúc.Khi tôi hỏi về việc sử dụng ORM để đơn giản hóa mã, tôi có cái nhìn trống vào mặt tiếp theo tất cả các tiêu cực của nó:

• của nó cao Bloat
• bạn không có kiểm soát tốt hơn các truy vấn của bạn và thực hiện những không cần thiết
• có một vật nặng để lập bản đồ bảng
• mã không khô của nó bởi vì bạn phải lặp lại tự bạn

trên một trên

Vâng, sau khi làm việc ở đó trong một vài tuần, tôi đã nhận thấy rằng:

• chúng tôi đã có một vài thắc mắc rằng gần như giống hệt nhau, và rất nhiều lần nếu có một lỗi, chỉ có một số ít sẽ được cố định
• thay vì bộ nhớ đệm truy vấn bảng chung, chúng tôi sẽ kết thúc đọc một bảng nhiều lần.
• Chúng tôi đã lặp lại bản thân của mình ở khắp nơi
• Chúng tôi có nhiều cấp độ kỹ năng, do đó một số truy vấn không được viết hiệu quả nhất.

Sau khi tôi chỉ ra hầu hết điều này, họ đã viết "DBO" vì không muốn gọi nó là ORM. Họ quyết định viết một từ đầu thay vì tinh chỉnh một cái.

Ngoài ra, nhiều lý lẽ đến từ sự thiếu hiểu biết đối với ORM tôi cảm thấy. Mỗi ORM mà tôi đã thấy cho phép truy vấn tùy chỉnh và thậm chí tuân theo các quy ước của ORM, bạn có thể viết các truy vấn rất phức tạp và chi tiết và thường có thể đọc được nhiều người hơn. Ngoài ra, chúng có xu hướng rất DRY, Bạn cung cấp cho họ lược đồ của bạn, và họ tìm ra phần còn lại, xuống bản đồ mối quan hệ.

ORM hiện đại có rất nhiều công cụ để giúp bạn, như kịch bản di chuyển, nhiều loại DB được truy cập vào cùng một đối tượng để bạn có thể tận dụng lợi thế của cả NOSQL và SQL DB. Nhưng bạn phải chọn đúng ORM cho dự án của bạn nếu bạn sử dụng nó.