Chúng ta có nên sử dụng Entity Framework không?

Chúng tôi hiện có ngăn xếp sau:

• VS 2005
• Các hình thức web
• Máy chủ SQL 2005
• IIS 6

Chúng tôi đang lên kế hoạch chuyển đổi sang đây:

• VS 2010
• Hình thức MVC và Web
• Máy chủ SQL 2008
• IIS 7

Câu hỏi của tôi là, khi chúng ta chuyển sang MVC với VS 2010, chúng ta có nên sử dụng Entity Framework (hoặc ORM khác), một ORM vi mô (như Massive ) hay chỉ là SQL đơn thuần?

Tất cả các hướng dẫn tôi đã đọc về VS 2010 đều hướng đến việc sử dụng Entity Framework cho các giao dịch dữ liệu, nhưng điều đó sẽ xuất hiện trong tương lai gần (5+ năm)?

Nếu có vấn đề, các ứng dụng của khách hàng của chúng tôi có thể có từ 10 - 1.000 người dùng hoạt động.

Gần đây tôi đã chuyển từ sử dụng các truy vấn SQL nội tuyến sang sử dụng EF và đây là những gì tôi đã tìm thấy:

Ưu

• Nhanh hơn nhiều để xây dựng DAL (thích không viết các truy vấn SQL!)
• Dễ dàng hơn nhiều để duy trì
• Không còn cần phải phân tích cú pháp đầu vào của tôi trước khi xây dựng câu lệnh sql nội tuyến, điều đó có nghĩa là ít có khả năng xảy ra cuộc tấn công SQL SQL hơn (tất nhiên, điều đó vẫn có thể tùy thuộc vào truy vấn của bạn, nhưng ít có khả năng hơn)

Nhược điểm

• Không thể mở rộng nhiều cơ sở dữ liệu ... ít nhất là không dễ dàng
• Tất cả các thực thể (bảng, dạng xem, v.v.) cần một khóa chính
• Nếu bạn muốn cập nhật một cột trong bảng hơn 100 cột bắt buộc (không phải thiết kế bảng của tôi), bạn phải kéo xuống tất cả 100 cột để thực hiện cập nhật. Hoặc sử dụng Thủ tục lưu trữ.
• Tôi đã gặp sự cố với một số giá trị mặc định được xác định trên máy chủ SQL không được đưa vào mô hình thực thể sau khi bản ghi mới được thêm vào. Thông thường, đây là với các giá trị được tính toán hoặc các giá trị được thêm vào trong Trình kích hoạt INSERT
• Đôi khi, các truy vấn SQL được viết kém và thực thi chậm. Nếu bạn có một truy vấn chạy chậm, hãy chạy theo dõi SQL để xem EF đang làm gì. Có thể bạn có thể làm việc lại truy vấn đó dưới dạng SP hoặc View. Điều này không xảy ra thường xuyên mặc dù.
• Tôi đã gặp một số vấn đề khi cố gắng tạo liên kết giữa các bảng không có Khóa ngoài được xác định trong SQL Server. Thông thường đó là vì tôi đang cố gắng tạo 1:0-1mối quan hệ nơi EF muốn sử dụng1:0-*

Tôi không phải là chuyên gia của EF, vì vậy tôi có thể đã bỏ lỡ một số điều. Đây chỉ là những mục tôi biết tôi đã gặp trong quá khứ khi chuyển từ SQL nội tuyến sang Entity Framework. Tôi rất vui vì tôi đã thực hiện chuyển đổi, nhưng đã có những lúc tôi thực sự ghét EF vì những điều kỳ quặc của nó.

Entity Framework là một công cụ năng suất. Trừ khi bạn có lý do chính đáng để không (EG bạn đang sử dụng SQL 2000 hoặc không có thời gian để phát triển công nghệ), sau đó sử dụng các công cụ tốt nhất theo ý của bạn.

Điều đó đang được nói, tôi thấy khái niệm Thực thể để dịch rất tốt cho Mô hình của mô hình MVC. Mặc dù có mối quan hệ 1: 1 với Mô hình và bảng là một thực tiễn tồi, nhưng suy nghĩ về các Thực thể có xu hướng tạo ra các thiết kế sạch, mã dễ đọc (đặc biệt là với LINQ).

Entity Framework được Microsoft hỗ trợ tích cực. Không ai có một quả cầu pha lê ma thuật để nói "sự hỗ trợ sẽ kéo dài X năm". Tôi thấy không có lý do gì để tin rằng Thực thể sẽ chết trong 5 năm tới.

Một giải pháp tiềm năng khác là sử dụng Thư viện khung thực thể thay thế không phải là thư viện được cung cấp với VS Có một số ít trên mạng.

Khái niệm khung công tác Entity / 3 lớp đã xuất hiện được một thời gian và đã làm việc với một số thư viện tùy chỉnh, giống như nhiều nhà phát triển khác, trước khi Microsoft phát hành khung "chính thức" của riêng mình.

Ưu

Có các lợi ích của khung Thực thể (DAL) mà không bị kẹt với các thay đổi thư viện / khung liên tục của Microsoft.

Thêm các tính năng vào thư viện có thể không có sẵn cho thư viện chính thức hiện có, như sử dụng một số thương hiệu dtabase.

Nhược điểm

Phải hỗ trợ thư viện hoặc công cụ. Nó rất phổ biến để có một công cụ mã trình tạo thực thể để tạo ra các enitites.

Bạn phải đưa ra quyết định kiến ​​trúc dựa trên vấn đề và giải pháp hiện có. Như với bất kỳ công nghệ có những lợi thế và bất lợi.

Tôi cá nhân thường sẽ sử dụng khung thực thể để phát triển mới nhưng không viết lại mã hiện có. Sau đó, bạn có được tốc độ cho việc xóa sổ trong tương lai nhưng không phải đầu tư nhiều thời gian để chuyển đổi mã. Nhược điểm của phương pháp đó là làm giảm tính nhất quán.

Trong tình huống của bạn, tôi chắc chắn sẽ sử dụng Entity Framework, tôi đã thấy nó hoạt động tốt với MVC.
Dưới đây là một số lý do thực sự và con trỏ.

• Linq là một niềm vui để sử dụng, và việc thực hiện bị trì hoãn cũng cực kỳ hữu ích.
• Bạn có thể tạo ra mô hình của bạn (tuy nhiên khi sử dụng với MVC Tôi muốn recomment bạn sử dụng xem các mô hình kết hợp với các mô hình dữ liệu, điều này làm cho xác nhận và mô hình ràng buộc rất nhiều dễ dàng hơn, nếu bạn làm mất rằng cách tiếp cận sử dụng automapper để lập bản đồ những thay đổi trở lại của bạn mô hình dữ liệu).

Tuy nhiên, có một số điều bạn sẽ cần tìm hiểu về cách sử dụng ORM.

• Bối cảnh làm gì cho bạn (theo dõi thực thể)
• Đó là một bối cảnh nên được sử dụng như một đơn vị công việc
• Hãy nhớ điều gì đó về đồng thời, EF có thể cho bạn biết khi nào đối tượng của bạn hết hạn nhưng có thể rất khó nếu bạn muốn xử lý đồng thời đúng cách qua các yêu cầu (vì bạn cần giữ dấu thời gian hoặc một cái gì đó).

Những điều cần cân nhắc

• Kích hoạt và ORM không hoạt động cùng nhau, thay vào đó hãy sử dụng các sự kiện ORM.
• Hãy chắc chắn rằng tất cả các bảng của bạn có khóa hứa hẹn.

Tôi cũng rất muốn giới thiệu cách tiếp cận mã đầu tiên, ngay cả khi bạn có cơ sở dữ liệu hiện có.

• Các quy ước có nghĩa là bạn không cần phải lấy lại ánh xạ hoặc các lớp khi bạn thay đổi cơ sở dữ liệu.
• Thật háo hức khi đặt xác nhận và logic khác trong các mô hình.
• Bạn có thể sử dụng trình tạo mã để giúp tạo chúng nếu bạn có một cơ sở dữ liệu lớn.