Khuôn khổ thực thể có quá tải đối với các ứng dụng web không?

Question

Giả sử chúng tôi đang phát triển một ứng dụng Web thương mại điện tử cho một doanh nghiệp vừa và nhỏ. Hãy tiếp tục giả định rằng doanh nghiệp có khả năng mở rộng theo thời gian. Nói cách khác, dòng sản phẩm thường sẽ phát triển.

Cho đến bây giờ tôi đã phát triển các giải pháp n-tier bằng cách sử dụng ADO.NET và các thủ tục được lưu trữ với sự trợ giúp của lớp SqlHelper. Đối với các ứng dụng lớn hơn, tôi đã sử dụng Thư viện doanh nghiệp (2.0).

Tôi muốn chuyển sang hướng tiếp cận dựa trên ORM và bắt đầu học LINQ cũng như chuyển đổi từ ASP.NET Web Forms sang ASP.NET MVC. Tôi không muốn đi với LINQ-to-SQL. Câu hỏi đặt ra là liệu ORM có bắt buộc hay không, nhưng nếu ORM Entity Framework là quá mức cần thiết cho một dự án như vậy. Tôi không quan tâm đến một đường cong học tập nếu nó được bảo hành cho nhiệm vụ trong tay.

Liên quan đến "quá mức cần thiết", tôi muốn biết nếu:

• EF là nhanh hơn so với một người nào đó với những kỹ năng đúng mã hóa các truy vấn bằng tay
• EF dẫn đến mã không cần thiết sưng lên
• EF cách không cần thiết shields devs từ chi tiết cấp mã truy vấn của họ
• LINQ to-Entities phù hợp cho các dự án có kích thước này

Thực tế, nếu có ai đó nghĩ rằng ORM là quá mức cần thiết cho dự án như vậy, tôi muốn nghe lý do tại sao.

Answer 1

EF không quá mức đối với các ứng dụng web.

Tôi không đồng ý với rất nhiều nội dung được nêu trong bài viết được tham chiếu của bạn. Tôi đồng ý devs nên có kỹ năng phong nha với SQL BUT ORMS làm một công việc tuyệt vời trong việc một công việc devs thực hiện nhanh hơn.

• Tốc độ ORMS - Họ đang nhận được tốt hơn tất cả các thời gian & chúng cho phép bạn để gọi SP hoặc sửa đổi các truy vấn để có được tốc độ tối đa khi cần thiết. Ngoài ra còn có các trình biên dịch tuyệt vời để theo dõi hiệu suất ORM như EFProf.

• Làm chậm quá trình mã hóa - Thực sự !!! Sau khi biết nó tăng tốc nó lên.

• Người phát triển cần biết SQL - Tôi đồng ý. Tuy nhiên, ORMS đặc biệt với cú pháp LINQ thường cho phép các nhà phát triển viết thêm SQL phức tạp hơn so với họ sẽ có trên của riêng họ.

• Devs viết các truy vấn hiệu quả đã - REALLLYYYY !!!! Chỉ cần hỏi DBA suy nghĩ của mình! Tôi tình cờ nghĩ rằng tôi cũng vậy nhưng mọi người khác cũng vậy. Xem vấn đề. :-)

• Mã Bloat - Phải không đồng ý, đặc biệt với những người có LINQ .... Nó thường làm cho mã dễ đọc hơn và giảm số lượng dòng thường xuyên.

• Quên về LINQ - Con tàu này có khởi hành. LINQ Rocks !!!! Đi với nó hoặc bị bỏ lại phía sau. Nó không chỉ được sử dụng trong ORMS. Nó có thể được sử dụng chống lại, mảng, đối tượng, XML, các tập tin, twitter và danh sách đi và về .... Nhận biết LINQ.

Bài viết nói về một số cảm hứng về những phát triển mới nhất của MS như đến từ Ruby on Rails. ROR có ORM dựa trên Bản ghi Hoạt động trong đó .....

ORMS là tốt. Chúng không cần phải được sử dụng ở mọi nơi và mọi lúc nhưng chúng tốt và cần được xem xét.

Answer 2

Chắc chắn không phải là quá mức cần thiết. Hãy tiếp tục và sử dụng EF.

Answer 3

EF có đường cong học tập, nhưng mọi thứ đều mới. EF không phải là quá mức cần thiết, nhưng theo bất kỳ hệ thống nào được viết đều sử dụng công nghệ phù hợp cho dự án phù hợp.

Answer 4

Nhìn vào bài viết, điều đầu tiên tôi sẽ xem và đồng ý với là thế này:

Tôi tin tưởng mạnh mẽ rằng web hiện đại nhà phát triển nên:

• Tình yêu cơ sở dữ liệu.

• Viết các truy vấn hiệu quả cao.

• Giảm thiểu mã.

• Thiết kế giao diện người dùng hiển nhiên.

• Làm việc nhanh chóng.

Tôi không chắc chắn có bao nhiêu người xem phát triển web, nhưng trong đầu tôi, một nhà phát triển web nên tập trung vào chức năng và quy tắc kinh doanh. Cơ sở dữ liệu thuần túy và mã SQL không bao giờ nên được thực hiện bởi một người nào đó trong nhóm của tôi sẽ viết mã chức năng kinh doanh hiệu quả hơn.

Đây là nơi mà khung Entity được phát. Nó được coi là một công cụ phát triển ứng dụng nhanh (như hầu hết các ORM khác). Những công cụ này được xây dựng đặc biệt để cho phép bạn tập trung hơn vào cách thực hiện các yêu cầu của người dùng và ít hơn vào cách viết đúng truy vấn.

Với điều đó đang được nói, tôi cũng sẽ nói rằng việc sử dụng công cụ này có thể rất nguy hiểm. Khi bạn sử dụng Entity Framework, bạn vẫn phải nhận thức được ý nghĩa của việc sử dụng đồ thị đối tượng mà bạn đang yêu cầu.

Đó là bởi đến nay không quá mức cần thiết, công cụ này rất đơn giản để sử dụng và đơn giản để tìm hiểu. Tôi cho rằng dễ dàng hơn để "sửa" một khung Entity thay vì sửa một bộ truy vấn SQL và bộ giao dịch ADO thô.

Trên các dự án nhỏ hơn, đề xuất cơ sở của tôi hầu như luôn đi kèm với một số loại ORM. Về các ứng dụng doanh nghiệp, bạn phải cẩn thận hơn một chút và hoàn toàn phụ thuộc vào ngân sách :-).

Answer 5

Mặc dù đây là một câu trả lời chung là cảnh giác với bất kỳ quan điểm trong đó có những ý kiến ​​trong:

"công cụ X stinks, tôi viết trong công cụ Y và tôi có thể làm điều đó nhanh hơn trong công cụ X".

Hoặc tất nhiên, một người nói tiếng Latinh nói tốt hơn bằng tiếng Latinh.

Answer 6

Điều này thực sự phụ thuộc vào độ phức tạp của mô hình dữ liệu của bạn thay vì loại ứng dụng.

Nếu bạn có một mô hình dữ liệu tương đối đơn giản, thì EF có thể quá mức cần thiết (nếu bạn chưa biết). Linq-to-SQL có thể là một lựa chọn tốt hơn (ít đường cong học tập hơn, mặc dù nó cũng có những hạn chế như không có ánh xạ nhiều-nhiều).

Nếu mô hình dữ liệu của bạn được chuẩn hóa hơn, thay vì chỉ dựa trên bảng thì EF chắc chắn sẽ trả hết trong thời gian dài hoặc nHibernate hoặc bất kỳ ORM nâng cao nào khác.

Bài viết bạn liên kết đến dường như chỉ ra rằng ORM nói chung là xấu, không chỉ EF. Khi đối mặt với những quan điểm của mình, anh ta dường như đã rút lui họ về một mức độ nào đó. Dường như anh ta đang cố biện minh cho một khái niệm chăn (các nhà phát triển mới phải học mã hóa cấp thấp, đặc biệt là SQL, trước khi đi tới các khuôn khổ cấp cao) bằng cách phát minh ra các điểm đáng nghi.

Answer 7

Một ORM có thể khá hữu ích, nếu được sử dụng đúng cách và bạn hiểu những gì nó đang làm cho bạn. Bạn chắc chắn nên sử dụng một, nếu bạn đã có một số hiểu biết về thiết kế cơ sở dữ liệu và truy vấn.

Điểm của bài viết, chủ yếu là khái niệm không phải học bất cứ điều gì về thiết kế cơ sở dữ liệu và truy vấn bằng cách nào đó làm cho cuộc sống của bạn tốt hơn là một sai lầm. Tôi thích các lớp trừu tượng rất mỏng giữa mã và cơ sở dữ liệu - tôi cảm thấy cho phép tôi tập trung hơn vào trải nghiệm người dùng tốt.

Cá nhân tôi cảm thấy báo chí đằng sau EF đang khuyến khích các lập trình viên mới bỏ qua một số khái niệm cơ bản cần thiết. Tôi đã làm việc với một số người trong số họ, và nghĩ rằng họ đã làm hại.

Tất nhiên, có những người sẽ rất không đồng ý. Không vấn đề gì!

Tôi biết các nhà phát triển đã bắt đầu yêu thích nó, và bây giờ thì không. Nhưng tôi cũng biết các nhà phát triển yêu thích EF và thề.

Tôi đã sử dụng EF, LINQ to SQL và NHibernate và những người khác trong những năm qua.

Lời khuyên tốt nhất: hãy dùng thử. Hãy đến kết luận của riêng bạn.

(Tiết lộ: Tôi là tác giả của bài viết bạn đã trích dẫn).