Trình tạo mã vs ORM

Question

Tôi đã viết trình tạo mã tạo các POCO và kho lưu trữ cho một cơ sở dữ liệu SQL Server/CE đã cho. Không có gì lạ mắt, chỉ có thủ tục CRUD đơn giản sử dụng ADO.Net cổ điển. Câu hỏi của tôi là, tại sao tôi nên sử dụng ORM như L2S/EF4 trên trình tạo mã tùy chỉnh? Mỗi 2 hoặc 3 năm, Microsoft cung cấp một số công nghệ/khung công tác truy cập dữ liệu mới và tôi biết khá ít nhà phát triển không thể luôn liên lạc với các công nghệ mới nhất, nhưng mỗi người đều biết ADO.Net cổ điển, cách sửa đổi mã hiện có và cách phát triển một chức năng mới. Các công cụ ORM có mang lại thứ gì đó phải là ngày nay, hay tôi có thể gắn bó với một ADO.Net cổ điển?

Cảm ơn bạn!

Answer 1

Nó thực sự phụ thuộc vào yêu cầu dự án và quy trình phát triển của bạn. ORM được đóng gói với rất nhiều whiz và mang lại nhiều niềm vui cho bảng, nhưng nếu bạn chỉ cần mua sắm cho một vài tính năng riêng biệt, bạn có thể tìm thấy các yêu cầu tinh thần/vật chất cần phải thất vọng. Điều đầu tiên bạn nên biết là có hai loại ORM: những sơ đồ hiện có cho logic ứng dụng (bạn quản lý lược đồ) và lược đồ logic ứng dụng bản đồ cho lược đồ (ORM quản lý giản đồ). Tốt nhất bạn nên tránh loại đầu tiên vì chúng không làm giảm bớt bạn phải làm/lặp lại công việc DBA đáng kể cho mỗi môi trường, nghĩa là bạn phải đảm bảo rằng tất cả các dev đều chạy một lược đồ thích hợp, ngoài việc đảm bảo chúng cũng đang chạy mã thích hợp. Loại thứ hai hoàn toàn có thể trừu tượng hóa thực tế bạn đang sử dụng cơ sở dữ liệu cơ bản, vì vậy chúng cho phép bạn tập trung vào miền ứng dụng, điều này làm cho các nhà phát triển hài lòng.

Không có DBA, không có nhiều nỗ lực phát triển cục bộ đối với một cá thể DB từ xa không thể quản lý được, không có nhiều sắc thái chéo RDBMS, không có nhiều thủ tục được lưu trữ, không có truy vấn với tham chiếu mã hoá cứng.

Vì vậy, tốt nhất là ORM của bạn nên:

• Tự động quản lý các giản đồ DB cho bạn
• Cung cấp một thực hiện tại chỗ của Active record pattern
• Really có thể để đóng gói tất cả các logic kinh doanh

Đường đẹp khác:

• Tự động quản lý di cư dữ liệu (nếu bạn mong đợi những thay đổi ontology thường xuyên như trái ngược với không có thay đổi)
• Hỗ trợ cho việc tạo ra/nhập khẩu đồ đạc

Hãy nhớ rằng bạn có thể bắt đầu bất kỳ dự án với một ORM như @Noon nói , nhưng bạn không thể bắt đầu mọi dự án mà không có nó ngay hôm nay. Lý tưởng nhất, ORMs là một sự phù hợp tuyệt vời cho các dự án mà bạn muốn các devs được toàn quyền kiểm soát hoặc bạn cần chúng để chạy các cá thể DB cục bộ. Dù bằng cách nào, đó là một bước tiến lớn từ cách tiếp cận ngược lại: yêu cầu DBA, uống cà phê cho đến khi DB được cập nhật, hy vọng nó sẽ xảy ra trong tuần.

Answer 2

Phụ thuộc; Bạn có thích làm việc bận rộn vô dụng với cơ sở dữ liệu, hoặc bạn muốn có nó tất cả tạo ra?

Nghiêm túc đấy, đối với tôi, hoàn toàn không có câu hỏi. Mỗi dự án đã biết nên bắt đầu bằng ORM và đối với tôi, LLBLGen là tốt nhất. Nó không phải là miễn phí mặc dù. Nhưng nó tiết kiệm rất nhiều thời gian trong việc phát triển các lớp dữ liệu, và cung cấp một cấu trúc tốt đẹp để làm việc với.

Thực sự, đó là vấn đề quyết định cách bạn muốn dành thời gian. Nếu bạn thấy giá trị trong làm việc trong lớp dữ liệu, vì một số lý do bạn có thể biện minh, khi cân nhắc chống lại một cái gì đó như LLBLGen, sau đó làm điều đó. Nhưng đối với tôi, tôi thì không.

Tất nhiên, tôi đồng ý với bạn, việc phải liên tục thay đổi ORM không phải là lý tưởng. Vì vậy, tôi đề nghị bạn dành một chút thời gian (có lẽ một vài tuần) để xác định cái nào là tốt nhất cho phong cách bạn muốn phát triển, và cách bạn cấu trúc các dự án của bạn, và sau đó đi cho nó. Hầu hết các cách chính được hỗ trợ rất tốt những ngày này anyway, vì vậy bạn không thể bị lỗi khi chọn một trong số họ và tiêu chuẩn hóa nó.

Answer 3

Đối với CRUD đơn giản và nếu các đối tượng đại diện cho trình tạo mã bảng giúp bạn đi thẳng đến mục tiêu của mình. ORMs ngày càng trở nên thú vị, nếu

• bạn đã làm phức tạp các mối quan hệ đối tượng và cần phải đi qua tham chiếu đối tượng,
• cần một số cơ chế bộ nhớ đệm,
• cần để đối phó với đồng thời đọc/viết,
• cần một số phiên bản của hàng bảng,
• phải đối phó với thừa kế,
• ...

Tóm lại: Nếu bạn cần thêm một ánh xạ đơn giản giữa một bảng và một đối tượng, thì các ORM có thể hữu ích. Vì vậy, bạn cần phải kiểm tra danh sách tính năng của ORM và tự hỏi mình nếu bạn cần.

Có một thứ thay thế ở giữa trình tạo mã và ORM toàn bộ: Trình lập bản đồ dữ liệu (như MyBatis trước đây được gọi là iBatis).

Answer 4

Một điểm có lợi cho ORM là kiểm tra thời gian biên dịch. Tôi sẽ sử dụng khung thực thể làm ví dụ, vì đó là những gì tôi sử dụng làm ORM.

Nếu bạn cần thay đổi giản đồ cơ sở dữ liệu trong quá trình phát triển (loại bỏ cột, bảng, v.v.), bạn cập nhật mô hình của mình từ cơ sở dữ liệu và sau đó biên dịch. Ở khắp mọi nơi mà cột hoặc bảng đã được tham chiếu bây giờ xuất hiện như là một lỗi thời gian biên dịch, làm cho nó dễ dàng để bắt lỗi mà có khả năng sẽ chỉ được chú ý trong thời gian chạy với ado.net tiêu chuẩn.

Một điều khác cần suy nghĩ là truy vấn đặc biệt - điều gì sẽ xảy ra nếu bạn muốn kéo chỉ một vài cột dữ liệu từ bảng? Với mã được tạo ra, bạn cần phải thêm một truy vấn mới, lớp để điền dữ liệu, v.v. Với một ORM, bạn có thể làm một cái gì đó như thế này, nơi một lớp ẩn danh được tạo ra cho bạn để bạn không phải trải qua công việc bận rộn tạo ra một mình.

Về cơ bản, ORM sẽ xử lý tất cả các trường hợp cạnh mà một giải pháp trồng tại nhà thường không.

var q = from c in ctx.contact 
     where c.contactId < 4 
     select c.firstName, c.lastName; 


foreach(var temp in q){ 
    string fullname = temp.firstName + " " + temp.LastName; 
} 

Answer 5

Tôi đã tham gia lập trình web, với các ngôn ngữ mới hơn thiếu xử lý dữ liệu thích hợp (dẫn đến nhu cầu nhận thức cho ORM) đồng thời tôi xây dựng trình tạo mã hoàn chỉnh. Chưa bao giờ nhìn lại.

Một lý do tôi sẽ không bao giờ xem xét ORM là vì tôi thực sự biết cơ sở dữ liệu hoạt động như thế nào, rất cảm ơn bạn.Tôi không có ý định làm cho nó trông giống như tôi không sử dụng cơ sở dữ liệu quan hệ, tôi muốn thứ gì đó giúp tôi có được sức mạnh của cơ sở dữ liệu với càng ít công việc càng tốt - và điều đó sẽ không bao giờ là ORM vì đó là không phải là những gì họ đang có. Theo kinh nghiệm của tôi, một trình tạo dựa trên từ điển tốt là chương trình DRY đúng nhất (không lặp lại chính mình), nó có thể giải phóng tôi khỏi việc chọn lựa và làm việc với DB và cho phép tôi tập trung vào những vấn đề quan trọng , nhận được logic biz tốt được viết trên đầu trang của một thiết kế bảng rắn.

EDIT: Hai điểm hơn:

1) Đi một con đường phi ORM là, nếu không có gì khác, cô đơn, bởi vì như ORM là rất nhiều những cơn thịnh nộ rất khó để tìm ra những người không bao giờ cần nó và không thấy điểm. Nhưng hãy để bản án kỹ thuật của bạn hướng dẫn bạn.

2) Một vài năm trước, tôi đã viết một mục blog, "Tại sao tôi không sử dụng ORM", mà tôi sẽ không liên kết vì nó quá nhạy cảm. Sau một thời gian, tôi cố gắng nắm bắt lại lý do tại sao có thể nhìn ORM một cách khách quan và thấy không có giá trị, mà không bị viêm, và liên kết đó là: http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html