Mã đầu tiên so với Mô hình / Cơ sở dữ liệu đầu tiên [đã đóng]

Những ưu và nhược điểm của việc sử dụng Entity Framework 4.1 Mã đầu tiên so với Mô hình / Cơ sở dữ liệu trước tiên với sơ đồ EDMX là gì?

Tôi đang cố gắng hiểu đầy đủ tất cả các phương pháp tiếp cận để xây dựng lớp truy cập dữ liệu bằng cách sử dụng EF 4.1. Tôi đang sử dụng mẫu Kho lưu trữ và IoC.

Tôi biết tôi có thể sử dụng cách tiếp cận mã đầu tiên: xác định thực thể và bối cảnh của mình bằng tay và sử dụng ModelBuilderđể tinh chỉnh lược đồ.

Tôi cũng có thể tạo EDMXsơ đồ và chọn bước tạo mã sử dụng các mẫu T4 để tạo các POCOlớp giống nhau .

Trong cả hai trường hợp, tôi kết thúc với POCOđối tượng là ORMthuyết bất khả tri và bối cảnh xuất phát từ đó DbContext.

Cơ sở dữ liệu đầu tiên dường như hấp dẫn nhất vì tôi có thể thiết kế cơ sở dữ liệu trong Trình quản lý doanh nghiệp, nhanh chóng đồng bộ mô hình và tinh chỉnh nó bằng trình thiết kế.

Vậy sự khác biệt giữa hai cách tiếp cận này là gì? Có phải chỉ là về ưu tiên VS2010 so với Enterprise Manager?

Tôi nghĩ rằng sự khác biệt là:

Mã đầu tiên

• Rất phổ biến vì các lập trình viên khó tính không thích bất kỳ loại nhà thiết kế nào và việc xác định ánh xạ trong EDMX xml quá phức tạp.
• Toàn quyền kiểm soát mã (không có mã tự tạo khó sửa đổi).
• Kỳ vọng chung là bạn không bận tâm với DB. DB chỉ là một bộ lưu trữ không có logic. EF sẽ xử lý việc tạo và bạn không muốn biết nó thực hiện công việc như thế nào.
• Các thay đổi thủ công cho cơ sở dữ liệu sẽ bị mất nhiều nhất vì mã của bạn xác định cơ sở dữ liệu.

Cơ sở dữ liệu đầu tiên

• Rất phổ biến nếu bạn có DB được thiết kế bởi các DBA, được phát triển riêng hoặc nếu bạn có DB hiện có.
• Bạn sẽ để EF tạo các thực thể cho bạn và sau khi sửa đổi ánh xạ, bạn sẽ tạo các thực thể POCO.
• Nếu bạn muốn các tính năng bổ sung trong các thực thể POCO, bạn phải sửa đổi mẫu T4 hoặc sử dụng các lớp một phần.
• Có thể thay đổi thủ công cơ sở dữ liệu vì cơ sở dữ liệu xác định mô hình miền của bạn. Bạn luôn có thể cập nhật mô hình từ cơ sở dữ liệu (tính năng này hoạt động khá tốt).
• Tôi thường sử dụng cùng nhau các dự án cơ sở dữ liệu VS (chỉ phiên bản Premium và Ultimate).

Mô hình đầu tiên

• IMHO phổ biến nếu bạn là người hâm mộ thiết kế (= bạn không thích viết mã hoặc SQL).
• Bạn sẽ "vẽ" mô hình của mình và để dòng công việc tạo tập lệnh cơ sở dữ liệu và mẫu T4 tạo các thực thể POCO của bạn. Bạn sẽ mất một phần quyền kiểm soát trên cả thực thể và cơ sở dữ liệu của mình, nhưng đối với các dự án nhỏ dễ dàng, bạn sẽ làm việc rất hiệu quả.
• Nếu bạn muốn các tính năng bổ sung trong các thực thể POCO, bạn phải sửa đổi mẫu T4 hoặc sử dụng các lớp một phần.
• Các thay đổi thủ công đối với cơ sở dữ liệu sẽ bị mất nhiều nhất vì mô hình của bạn xác định cơ sở dữ liệu. Điều này hoạt động tốt hơn nếu bạn đã cài đặt gói năng lượng tạo cơ sở dữ liệu. Nó sẽ cho phép bạn cập nhật lược đồ cơ sở dữ liệu (thay vì tạo lại) hoặc cập nhật các dự án cơ sở dữ liệu trong VS.

Tôi hy vọng rằng trong trường hợp của EF 4.1, có một số tính năng khác liên quan đến Code First so với Model / Database trước tiên. API thông thạo được sử dụng trong Code trước tiên không cung cấp tất cả các tính năng của EDMX. Tôi hy vọng rằng các tính năng như ánh xạ thủ tục được lưu trữ, chế độ xem truy vấn, xác định chế độ xem, v.v ... hoạt động khi sử dụng Mô hình / Cơ sở dữ liệu trước tiên và DbContext(tôi chưa thử nó) nhưng trước tiên chúng không có trong Mã.

Tôi nghĩ rằng "cây quyết định" đơn giản này của Julie Lerman, tác giả của "Khung thực thể lập trình" sẽ giúp đưa ra quyết định một cách tự tin hơn:

Thêm thông tin ở đây .

Cơ sở dữ liệu đầu tiên và mô hình đầu tiên không có sự khác biệt thực sự. Mã được tạo là như nhau và bạn có thể kết hợp phương pháp này. Ví dụ: bạn có thể tạo cơ sở dữ liệu bằng trình thiết kế, hơn là bạn có thể thay đổi cơ sở dữ liệu bằng cách sử dụng tập lệnh sql và cập nhật mô hình của mình.

Khi bạn sử dụng mã trước tiên, bạn không thể thay đổi mô hình mà không có cơ sở dữ liệu giải trí và mất tất cả dữ liệu. IMHO, giới hạn này rất nghiêm ngặt và không cho phép sử dụng mã đầu tiên trong sản xuất. Để bây giờ nó không thực sự có thể sử dụng.

Nhược điểm nhỏ thứ hai của mã trước tiên là trình xây dựng mô hình yêu cầu các đặc quyền trên cơ sở dữ liệu chủ. Điều này không ảnh hưởng đến bạn nếu bạn sử dụng cơ sở dữ liệu SQL Server Compact hoặc nếu bạn kiểm soát máy chủ cơ sở dữ liệu.

Ưu điểm của mã đầu tiên là mã rất sạch và đơn giản. Bạn có toàn quyền kiểm soát mã này và có thể dễ dàng sửa đổi và sử dụng nó làm mô hình xem của bạn.

Tôi có thể khuyên bạn nên sử dụng cách tiếp cận mã đầu tiên khi bạn tạo ứng dụng độc lập đơn giản mà không cần phiên bản và sử dụng model \ cơ sở dữ liệu trước trong các dự án yêu cầu sửa đổi trong sản xuất.

Trích dẫn các phần có liên quan từ http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework

3 lý do để sử dụng mã thiết kế đầu tiên với Entity Framework

1) Ít hành trình, ít phình to

Sử dụng cơ sở dữ liệu hiện có để tạo tệp mô hình .edmx và các mô hình mã được liên kết dẫn đến một đống mã được tạo tự động khổng lồ. Bạn được ngụ ý không bao giờ chạm vào những tệp được tạo này vì sợ bạn phá vỡ thứ gì đó hoặc những thay đổi của bạn sẽ bị ghi đè lên thế hệ tiếp theo. Bối cảnh và trình khởi tạo cũng bị kẹt trong mớ hỗn độn này. Khi bạn cần thêm chức năng cho các mô hình đã tạo, như thuộc tính chỉ đọc được tính toán, bạn cần mở rộng lớp mô hình. Điều này kết thúc là một yêu cầu cho hầu hết mọi mô hình và bạn kết thúc với một phần mở rộng cho tất cả mọi thứ.

Với mã đầu tiên các mô hình mã hóa tay của bạn trở thành cơ sở dữ liệu của bạn. Các tệp chính xác mà bạn đang xây dựng là những gì tạo ra thiết kế cơ sở dữ liệu. Không có tệp bổ sung và không cần tạo tiện ích mở rộng lớp khi bạn muốn thêm thuộc tính hoặc bất cứ thứ gì khác mà cơ sở dữ liệu không cần biết. Bạn chỉ có thể thêm chúng vào cùng một lớp miễn là bạn làm theo cú pháp thích hợp. Heck, bạn thậm chí có thể tạo một tệp Model.edmx để trực quan hóa mã của bạn nếu bạn muốn.

2) Kiểm soát tốt hơn

Khi bạn đi DB trước, bạn sẽ cảm thấy thoải mái với những gì được tạo cho các mô hình của mình để sử dụng trong ứng dụng của bạn. Đôi khi quy ước đặt tên là không mong muốn. Đôi khi các mối quan hệ và hiệp hội không hoàn toàn như bạn muốn. Những lần khác, mối quan hệ không nhất thời với việc lười biếng tải sẽ tàn phá các phản hồi API của bạn.

Mặc dù hầu như luôn luôn có một giải pháp cho các vấn đề tạo mô hình mà bạn có thể gặp phải, nhưng trước tiên, mã sẽ cung cấp cho bạn quyền kiểm soát hoàn chỉnh và chi tiết ngay từ đầu. Bạn có thể kiểm soát mọi khía cạnh của cả mô hình mã và thiết kế cơ sở dữ liệu của bạn một cách thoải mái cho đối tượng kinh doanh của bạn. Bạn có thể chỉ định chính xác các mối quan hệ, các ràng buộc và các hiệp hội. Bạn có thể đồng thời đặt giới hạn ký tự thuộc tính và kích thước cột cơ sở dữ liệu. Bạn có thể chỉ định những bộ sưu tập liên quan nào sẽ được tải háo hức hoặc hoàn toàn không được đăng. Nói tóm lại, bạn chịu trách nhiệm cho nhiều thứ hơn nhưng bạn có toàn quyền kiểm soát thiết kế ứng dụng của mình.

3) Kiểm soát phiên bản cơ sở dữ liệu

Đây là một vấn đề lớn. Phiên bản cơ sở dữ liệu là khó, nhưng với mã di chuyển đầu tiên và mã di chuyển đầu tiên, nó hiệu quả hơn nhiều. Vì lược đồ cơ sở dữ liệu của bạn hoàn toàn dựa trên các mô hình mã của bạn, theo phiên bản kiểm soát mã nguồn của bạn, bạn sẽ giúp phiên bản cơ sở dữ liệu của mình. Bạn chịu trách nhiệm kiểm soát việc khởi tạo ngữ cảnh của mình, điều này có thể giúp bạn thực hiện những việc như khởi tạo dữ liệu cố định. Bạn cũng chịu trách nhiệm tạo mã di chuyển đầu tiên.

Khi bạn lần đầu tiên kích hoạt di chuyển, một lớp cấu hình và di chuyển ban đầu được tạo. Di chuyển ban đầu là lược đồ hiện tại của bạn hoặc đường cơ sở v1.0 của bạn. Từ thời điểm đó, bạn sẽ thêm các lần di chuyển được đánh dấu thời gian và được gắn nhãn với một mô tả để giúp sắp xếp các phiên bản. Khi bạn gọi bổ sung di chuyển từ trình quản lý gói, một tệp di chuyển mới sẽ được tạo tự động chứa mọi thứ đã thay đổi trong mô hình mã của bạn trong cả hàm UP () và DOWN (). Hàm UP áp dụng các thay đổi cho cơ sở dữ liệu, hàm DOWN sẽ loại bỏ những thay đổi tương tự trong trường hợp bạn muốn khôi phục. Hơn thế nữa, bạn có thể chỉnh sửa các tệp di chuyển này để thêm các thay đổi bổ sung như chế độ xem mới, chỉ mục, quy trình được lưu trữ và bất cứ điều gì khác. Chúng sẽ trở thành một hệ thống phiên bản thực sự cho lược đồ cơ sở dữ liệu của bạn.

Code-đầu tiên dường như là ngôi sao đang lên. Tôi đã có một cái nhìn nhanh về Ruby on Rails, và tiêu chuẩn của họ là mã đầu tiên, với việc di chuyển cơ sở dữ liệu.

Nếu bạn đang xây dựng một ứng dụng MVC3, tôi tin rằng Code trước tiên có những ưu điểm sau:

• Trang trí thuộc tính dễ dàng - Bạn có thể trang trí các trường với xác thực, yêu cầu, v.v. các thuộc tính, khá khó xử với mô hình hóa EF
• Không có lỗi mô hình kỳ lạ - Mô hình hóa EF thường có các lỗi lạ, chẳng hạn như khi bạn cố đổi tên một thuộc tính kết hợp, nó cần khớp với dữ liệu meta cơ bản - rất không linh hoạt.
• Không ngại hợp nhất - Khi sử dụng các công cụ kiểm soát phiên bản mã như đồng bóng, việc hợp nhất các tệp .edmx là một nỗi đau. Bạn là một lập trình viên đã từng sử dụng C # và ở đó bạn đang hợp nhất một .edmx. Không phải như vậy với mã đầu tiên.
• Tương phản trở lại Mã trước tiên và bạn có toàn quyền kiểm soát mà không có tất cả các phức tạp và ẩn số để giải quyết.
• Tôi khuyên bạn nên sử dụng công cụ dòng lệnh Trình quản lý gói, thậm chí không sử dụng các công cụ đồ họa để thêm bộ điều khiển mới vào khung nhìn.
• Di chuyển DB - Sau đó, bạn cũng có thể Kích hoạt di chuyển. Điều này thật mạnh mẽ. Bạn thực hiện các thay đổi cho mô hình của mình bằng mã, và sau đó khung có thể theo dõi các thay đổi lược đồ, do đó bạn có thể triển khai liền mạch các nâng cấp, với các phiên bản lược đồ được tự động nâng cấp (và hạ cấp nếu cần). (Không chắc chắn, nhưng điều này có lẽ cũng hoạt động với mô hình đầu tiên)

Cập nhật

Câu hỏi cũng yêu cầu so sánh mã đầu tiên với mô hình EDMX / db-trước. Mã đầu tiên có thể được sử dụng cho cả hai cách tiếp cận này:

• Model-First : Mã hóa POCO trước (mô hình khái niệm) sau đó tạo cơ sở dữ liệu (di chuyển); HOẶC LÀ
• Cơ sở dữ liệu-Đầu tiên : Đưa ra một cơ sở dữ liệu hiện có, mã hóa thủ công các POCO để khớp. (Sự khác biệt ở đây là các POCO không được tạo tự động cung cấp cho cơ sở dữ liệu hiện có). Tuy nhiên, bạn có thể tiến gần đến tự động bằng cách sử dụng Tạo các lớp POCO và ánh xạ cho cơ sở dữ liệu hiện có bằng Entity Framework hoặc Entity Framework 5 - Cách tạo các lớp POCO từ cơ sở dữ liệu hiện có .

Tôi sử dụng cơ sở dữ liệu EF trước để cung cấp sự linh hoạt và kiểm soát hơn đối với cấu hình cơ sở dữ liệu.

Mã đầu tiên và mô hình đầu tiên có vẻ mát mẻ lúc đầu và cung cấp tính độc lập cho cơ sở dữ liệu, tuy nhiên khi thực hiện việc này, nó không cho phép bạn chỉ định những gì tôi cho là thông tin cấu hình cơ sở dữ liệu rất cơ bản và phổ biến. Ví dụ: chỉ mục bảng, siêu dữ liệu bảo mật hoặc có khóa chính chứa nhiều hơn một cột. Tôi thấy tôi muốn sử dụng những tính năng này và các tính năng cơ sở dữ liệu phổ biến khác và do đó phải thực hiện một số cấu hình cơ sở dữ liệu trực tiếp.

Tôi thấy các lớp POCO mặc định được tạo trong DB trước tiên rất sạch sẽ, tuy nhiên thiếu các thuộc tính chú thích dữ liệu rất hữu ích hoặc ánh xạ cho các thủ tục được lưu trữ. Tôi đã sử dụng các mẫu T4 để khắc phục một số hạn chế này. Các mẫu T4 là tuyệt vời, đặc biệt là khi kết hợp với siêu dữ liệu của riêng bạn và các lớp một phần.

Mô hình đầu tiên dường như có rất nhiều tiềm năng, nhưng đang mang lại cho tôi rất nhiều lỗi trong quá trình tái cấu trúc lược đồ cơ sở dữ liệu phức tạp. Không chắc chắn lý do tại sao.

Làm việc với các mô hình lớn rất chậm trước SP1, (chưa thử nó sau SP1, nhưng người ta nói rằng đó là một snap ngay bây giờ).

Tôi vẫn thiết kế các bảng của mình trước, sau đó một công cụ được xây dựng trong nhà tạo ra các POCO cho tôi, do đó, nó chịu trách nhiệm thực hiện các nhiệm vụ lặp đi lặp lại cho mỗi đối tượng poco.

Khi bạn đang sử dụng các hệ thống kiểm soát nguồn, bạn có thể dễ dàng theo dõi lịch sử của POCO của mình, điều đó không dễ dàng với mã được thiết kế tạo.

Tôi có một cơ sở cho POCO của mình, điều này làm cho rất nhiều thứ khá dễ dàng.

Tôi có các chế độ xem cho tất cả các bảng của mình, mỗi chế độ xem cơ sở mang lại thông tin cơ bản cho các khóa ngoại của tôi và các POCO xem của tôi xuất phát từ các lớp POCO của tôi, một lần nữa khá hữu ích.

Và cuối cùng tôi không thích nhà thiết kế.

Ví dụ về cách tiếp cận cơ sở dữ liệu:

Không cần viết bất kỳ mã nào: Cơ sở dữ liệu ASP.NET MVC / MVC3 Cách tiếp cận / cơ sở dữ liệu đầu tiên

Và tôi nghĩ nó tốt hơn các cách tiếp cận khác vì mất dữ liệu ít hơn với cách tiếp cận này.

IMHO Tôi nghĩ rằng tất cả các mô hình đều có một vị trí tuyệt vời nhưng vấn đề tôi gặp phải với cách tiếp cận mô hình đầu tiên là ở nhiều doanh nghiệp lớn với DBA đang kiểm soát cơ sở dữ liệu mà bạn không có được sự linh hoạt của việc xây dựng các ứng dụng mà không sử dụng các phương pháp tiếp cận cơ sở dữ liệu. Tôi đã làm việc trên nhiều dự án và khi bắt đầu triển khai, họ muốn kiểm soát hoàn toàn.

Vì vậy, nhiều như tôi đồng ý với tất cả các biến thể có thể Mã đầu tiên, Mô hình đầu tiên, Cơ sở dữ liệu trước tiên, bạn phải xem xét môi trường sản xuất thực tế. Vì vậy, nếu hệ thống của bạn sẽ là một ứng dụng cơ sở người dùng lớn với nhiều người dùng và DBA đang chạy chương trình thì bạn có thể xem xét tùy chọn Cơ sở dữ liệu đầu tiên chỉ là ý kiến ​​của tôi.

Tôi nghĩ một trong những Ưu điểm của mã trước tiên là bạn có thể sao lưu tất cả các thay đổi bạn đã thực hiện đối với hệ thống kiểm soát phiên bản như Git. Bởi vì tất cả các bảng và các mối quan hệ của bạn được lưu trữ trong những gì thực chất chỉ là các lớp, bạn có thể quay ngược thời gian và xem cấu trúc cơ sở dữ liệu của bạn trước đó là gì.