Một số đối số CHỐNG LẠI khi sử dụng EntityFramework là gì? [đóng cửa]

Ứng dụng tôi hiện đang xây dựng đã sử dụng các thủ tục được lưu trữ và các mô hình lớp thủ công để thể hiện các đối tượng cơ sở dữ liệu. Một số người đã đề xuất sử dụng Entity Framework và tôi đang xem xét chuyển sang đó vì tôi không tham gia dự án. Vấn đề của tôi là, tôi cảm thấy những người tranh luận về EF chỉ nói cho tôi biết mặt tốt của mọi thứ chứ không phải mặt xấu :)

Mối quan tâm chính của tôi là:

• Chúng tôi muốn xác thực phía máy khách bằng cách sử dụng DataAnnotations và có vẻ như tôi phải tạo các mô hình phía máy khách bằng mọi cách vì vậy tôi không chắc chắn rằng EF sẽ tiết kiệm được nhiều thời gian mã hóa đó
• Chúng tôi muốn giữ cho các lớp càng nhỏ càng tốt khi truy cập mạng và tôi đã đọc được rằng sử dụng EF thường bao gồm các dữ liệu bổ sung không cần thiết
• Chúng tôi có một lớp cơ sở dữ liệu phức tạp vượt qua nhiều cơ sở dữ liệu và tôi không chắc rằng EF có thể xử lý việc này. Chúng tôi có một cơ sở dữ liệu chung với những thứ như Người dùng, StatusCodes, Loại, v.v. và nhiều phiên bản của cơ sở dữ liệu chính của chúng tôi cho các phiên bản khác nhau của ứng dụng. Các truy vấn CHỌN có thể và sẽ truy vấn trên tất cả các phiên bản của cơ sở dữ liệu, tuy nhiên người dùng chỉ có thể sửa đổi các đối tượng trong cơ sở dữ liệu mà họ hiện đang làm việc. Họ có thể chuyển đổi cơ sở dữ liệu mà không cần tải lại ứng dụng.
• Các chế độ đối tượng rất phức tạp và thường có khá nhiều liên kết tham gia

Các đối số cho EF là:

• Đồng thời. Tôi sẽ không phải viết mã trong kiểm tra để xem bản ghi đã được cập nhật trước mỗi lần lưu chưa
• Tạo mã. EF có thể tạo các mô hình lớp và POCO một phần cho tôi, tuy nhiên tôi không tích cực, điều này thực sự sẽ giúp tôi tiết kiệm được nhiều thời gian vì tôi nghĩ chúng ta vẫn cần tạo các mô hình phía máy khách để xác thực và một số phương pháp phân tích tùy chỉnh.
• Tốc độ phát triển vì chúng ta sẽ không cần tạo các thủ tục lưu sẵn CRUD cho mọi đối tượng cơ sở dữ liệu

Kiến trúc hiện tại của chúng tôi bao gồm Dịch vụ WPF xử lý các cuộc gọi cơ sở dữ liệu thông qua các Thủ tục lưu trữ được tham số hóa, các đối tượng POCO đi đến / từ dịch vụ WCF và ứng dụng khách WPF và máy khách máy tính để bàn WPF chuyển đổi POCO thành Mô hình lớp cho mục đích Xác thực và Liên kết dữ liệu.

Vì vậy, câu hỏi của tôi là, liệu EF có phù hợp với điều này? Có bất kỳ cạm bẫy nào về EF mà tôi không biết?

Gần đây tôi đã đánh giá Entity Framework và nơi tốt nhất tôi tìm thấy cho các sự cố và tính năng bị thiếu là: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Các mục có nhiều phiếu bầu nhất:

1. Hỗ trợ cho enum. Cái này khá lớn, nhưng hiện tại có một số cách giải quyết
2. Cải thiện thế hệ SQL. Tốc độ thực sự quan trọng đặc biệt đối với các ứng dụng cấp doanh nghiệp, nhưng có vẻ như với EF4, nó đã được cải thiện rất nhiều
3. Hỗ trợ nhiều cơ sở dữ liệu. Yêu cầu cho bất kỳ ứng dụng lớn.

Có nhiều vấn đề hơn trong danh sách Thoại người dùng.

Bên cạnh đó, tôi khá hào hứng về việc phát hành sắp tới của EF 4.1 sẽ bao gồm cách tiếp cận Code-First ... http://bloss.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-phát hành-ứng cử viên-có sẵn.aspx

Điều này thực sự có thể thúc đẩy tôi thử dùng EF trong một ứng dụng sản xuất.

Làm chi nhánh cho mỗi lỗi / tính năng với EF có thể gây đau đớn đáng kể tại thời điểm hợp nhất. Hãy tưởng tượng rằng hai nhánh A và B thực hiện thay đổi cơ sở dữ liệu (điều này có thể sẽ xảy ra rất nhiều trong giai đoạn đầu của một dự án mới).

Bạn hợp nhất tất cả các tệp "bình thường" - tệp cs, v.v. Và sau đó là thời gian để hợp nhất Model.edmx. Và đột nhiên, bạn không chỉ hợp nhất các ánh xạ logic giữa mô hình đối tượng và cơ sở dữ liệu, mà cả các vị trí của các bảng trong sơ đồ thực thể.

Sáp nhập Model.edmx đau đớn đến nỗi chúng tôi đã áp dụng một cách khá khó chịu mà hoạt động:

• Trong quá trình hợp nhất, chỉ cần chọn tất cả các hợp nhất từ ​​một cha mẹ. Điều đó không quan trọng; bạn sẽ sớm nướng tập tin này:
• Hoàn nguyên Model.edmx cho cha hoặc mẹ.
• Di chuyển cơ sở dữ liệu của bạn sang trạng thái hợp nhất mới.
• Mở Model.edmx và "Cập nhật mô hình từ cơ sở dữ liệu".
• Đổi tên tất cả các thuộc tính điều hướng nướng trong quá trình hợp nhất.

Có một vài lợi ích khác đối với EF mà bạn đang thiếu:

• Bạn có thể có một bảng nhịp Entity
• Bạn có thể chia bảng thành nhiều loại Thực thể
• Bạn có thể tạo các Thực thể từ cơ sở dữ liệu (nghĩa là cơ sở dữ liệu dưới dạng phương pháp chính)
• Bạn có thể tạo cơ sở dữ liệu từ Thực thể (tức là mã dưới dạng tiếp cận chính)
• Các truy vấn LINQ được dịch sang các truy vấn SQL, cải thiện hiệu suất của chúng.

Nhược điểm (đặc biệt nếu bạn đang sử dụng xác nhận):

• Bạn phải tạo một thuộc tính [MetadataClass] trỏ đến một lớp khác có các thuộc tính bạn muốn xác thực bằng các thuộc tính xác thực phù hợp. Tất cả các thuộc tính là objectcác loại, vì vậy nó chỉ ở đó để đọc siêu dữ liệu. Vẫn còn rất nhiều mã không hoạt động.
• Sử dụng EntityFramework là một khái niệm khác với cách mà NHibernate (và cả phiên bản Java gốc) được thiết kế để hoạt động. EntityFramework hoạt động tốt nhất trong chế độ đính kèm trong đó các đối tượng đang sử dụng kết nối trực tiếp mọi lúc. NHibernate và các công cụ ORM tương tự hoạt động tốt nhất ở chế độ tách rời , nơi kết nối chỉ được sử dụng khi tải / lưu dữ liệu.

Đó là hai khiếu nại lớn nhất mà tôi có. Có một số lợi ích, nhưng bạn rất có thể có thể nhận được những lợi ích tương tự từ NHibernate. Nếu EntityFramework nằm trên bàn, nhóm cũng sẽ kiểm tra NHibernate và thực hiện nhanh chóng các ưu / nhược điểm cho dự án của bạn .

Vấn đề lớp siêu dữ liệu là một vấn đề đau đầu, nhưng rất may tôi chỉ có rất nhiều thực thể cần thẻ xác thực.

Thiếu chế độ tách rời thực sự cho các đối tượng của bạn giới hạn những gì bạn có thể làm trong môi trường web. Chế độ đính kèm tốt hơn cho các ứng dụng máy tính để bàn, đó là nơi bắt nguồn của một số sáng kiến ​​của Microsoft. Chế độ tách rời là có thể , nhưng rất đau đớn. Tốt nhất là sử dụng một công cụ thay thế trong trường hợp này.

Một điều Microsoft không phải là rất tốt tại là lạc hậu so sánh tính tương thích, đặc biệt là khi nói đến các công nghệ mới

Cụ thể, EF1 (.net 3.5) rất khác so với EF4 (.net 4.0) - điều tương tự có thể xảy ra đối với phiên bản tiếp theo.

Tôi sẽ đợi một lúc và xem công nghệ trưởng thành như thế nào.

Trong lúc này, hãy cân nhắc sử dụng nHibernate - nó không tương đương, nhưng nó trưởng thành và được sử dụng một cách điên cuồng.

• Đơn giản là ... Mô hình miền hiếm khi là một bản sao của mô hình quan hệ trong cơ sở dữ liệu của bạn. Vì vậy, ánh xạ một số bảng tới một lớp và ném nó qua dây chỉ là sự lười biếng. Các bảng có thể ánh xạ cục bộ thành 1 đối tượng mặc dù cơ sở dữ liệu là 3 bảng khác nhau. Thiết kế cơ sở dữ liệu thông minh.
• Thứ 2 thứ này không thể tạo ra các truy vấn nhất định và bạn sẽ phải viết chúng bằng mọi cách.
• Thứ 3 Mô hình miền không ánh xạ trực tiếp vào các dịch vụ .. Người ta sẽ chỉ muốn đẩy tập hợp dữ liệu tối thiểu nhất qua dây như DTOs .. đặc biệt, nếu nó sẽ giao tiếp với các ứng dụng di động.
• Khả năng kiểm tra 5 ... Không thể tạo các thử nghiệm đủ chi tiết sẽ cung cấp đủ hồi quy chống lại thay đổi mã ... tất cả để dễ dàng
  phá vỡ ...

Tôi có thể viết một diatribe 10 trang. Nhưng, nếu bạn chỉ viết một số ứng dụng vứt đi cho Công ty X .. thì ai cũng quan tâm. Nhưng, nếu bạn đang phát triển một sản phẩm phần mềm ... bạn sẽ phải làm hậu môn nhiều hơn

Hãy xem điều này: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Những điểm chính là:

• Thiếu tải
• Thiếu kiên trì thiếu hiểu biết
• Định dạng tệp được sử dụng để lưu mô hình thực thể chứa cả các yếu tố trực quan và chính mô hình thực thể gây ra sự cố hợp nhất trong môi trường nhóm.

Lưu ý rằng liên kết trên đang nói về EF1.

Ngoài ra liên kết này: http://ormeter.net/ cho thấy rằng EF không phải là tốt nhất so với các ORM khác về hiệu suất và hỗ trợ LINQ.