CodeFirst dành cho các ứng dụng quy mô lớn?

Tôi đã đọc về Entity Framework, đặc biệt là EF 4.1 và theo liên kết này ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) và hướng dẫn về Code First.

Tôi thấy nó gọn gàng nhưng tôi đã tự hỏi, liệu Code First có phải chỉ là một giải pháp cho sự phát triển nhanh chóng mà bạn có thể nhảy ngay vào mà không cần lập kế hoạch nhiều hay nó thực sự được sử dụng cho các ứng dụng quy mô lớn?

Tôi có thể có một số kẻ gièm pha ngoài kia, nhưng khi tôi đọc một số bài đăng đó từ Hanselman và Gutherie, sau đó đọc cuốn sách của Julia Lerman trên Entity Framework, trước tiên tôi đã gặp khó khăn với mã. Trong nhiều năm xây dựng các ứng dụng của mình, tôi đã đi qua nhiều con đường, cả bị ép buộc bởi quá trình và do lựa chọn, và nhận thấy rằng tôi đã thành công hơn nhiều khi thực hiện chế độ xem tập trung vào dữ liệu khi xây dựng ứng dụng.

Tôi đang nói về dòng ứng dụng kinh doanh ở đây ... đây là khi bạn gặp vấn đề hoặc quy trình kinh doanh cần có giải pháp phần mềm đằng sau nó. Bạn có dữ liệu cần được quản lý theo một cách nào đó. Tốt hơn là nên biết dữ liệu của bạn và cách nó liên quan đến chính nó và cách nó được sử dụng trong doanh nghiệp. Do đó, bạn mô hình hóa dữ liệu đó và sau đó tạo một ứng dụng / giải pháp xung quanh nó. Theo kinh nghiệm của tôi, nếu bạn bắt đầu tạo ứng dụng với dữ liệu như suy nghĩ lại, cuối cùng sẽ có thứ gì đó bị loại bỏ, và sau đó bạn có một số cấu trúc lại (trong nhiều trường hợp - tái cấu trúc MAJOR).

Các ứng dụng nhỏ có thể là một ngoại lệ, nhưng tôi sẽ tiếp tục sử dụng phương pháp tập trung vào dữ liệu của mình.

Tôi không hiểu tại sao CodeFirst không thể được sử dụng trong các dự án doanh nghiệp lớn. Tôi sẽ nói rằng tôi sử dụng EF CodeFirst trong một số dự án, một dự án trong đó cơ sở dữ liệu được tạo bởi mô hình EF CodeFirst của tôi và lần thứ 2 nơi EF CodeFirst được ánh xạ tới cơ sở dữ liệu hiện có.

Từ kinh nghiệm của tôi, CF hiệu quả như thế nào trong một dự án lớn phụ thuộc rất nhiều vào mức độ trừu tượng của lớp dữ liệu của bạn từ lớp doanh nghiệp của bạn.

Ví dụ, trong một trong các dự án của tôi, lớp nghiệp vụ gọi trực tiếp cơ sở dữ liệu thông qua linq. Tôi sử dụng Linq để trừu tượng hóa lớp cơ sở dữ liệu của mình và sử dụng CodeFirst để ánh xạ các POCO của tôi vào lược đồ cơ sở dữ liệu. Trong trường hợp này, CodeFirst làm cho hành động duy trì sự khác biệt giữa các quy ước DB (tên mối quan hệ và tên bảng) và tên lớp C # của tôi đơn giản hơn nhiều và tôi có thể thay đổi cơ sở dữ liệu mà không phải ảnh hưởng nhiều đến cách lớp doanh nghiệp của tôi tương tác với cơ sở dữ liệu.

Tuy nhiên, trong một dự án khác, tôi đã trừu tượng hóa quyền truy cập cơ sở dữ liệu vào một mẫu kho lưu trữ không chung chung và các phương thức Get * của kho lưu trữ của tôi chỉ chịu trách nhiệm chạy các truy vấn trên cơ sở dữ liệu và chúng trả về các đối tượng thực (không phải IQueryable<T>s). Trong trường hợp này, các phương thức kho lưu trữ đang chuyển đổi các thực thể DB thành các thực thể POCO và trong trường hợp này CodeFirst không mang lại nhiều lợi ích cho bạn vì các POCO của CodeFirst tồn tại trong thời gian ngắn và được chuyển đổi nhanh chóng thành các lớp C # của lớp nghiệp vụ.

Cuối cùng, nó thực sự phụ thuộc vào cách cấu trúc nhóm và mức độ thoải mái của nhóm (hoặc người cao niên) với các kỹ sư không phải DBA sửa đổi lược đồ cơ sở dữ liệu và mức độ thay đổi lược đồ sẽ ảnh hưởng đến cấu trúc mã của bạn. Với CodeFirst được ánh xạ tới cơ sở dữ liệu hiện có, việc tôi sắp xếp lại một thuộc tính thành một tên cột mới mà không cần phải đổi tên toàn cầu, đó là một yếu tố khi bạn nói về một tên có ý nghĩa hơn cho trường cơ sở dữ liệu thay vì thuộc tính C #. Tôi cũng rất ít khi thêm hỗ trợ mã cho các trường cơ sở dữ liệu mới mà không phải sửa lại hoàn toàn các thực thể C # của mình (một trong những lý do khiến tôi rời Linq-to-sql sang EF CodeFirst từ cơ sở dữ liệu hiện có).

Code First không phù hợp cho các ứng dụng quy mô lớn. Vòng quay phát triển ứng dụng quy mô lớn là rất lớn.

Thông thường vòng đời của ứng dụng kinh doanh của bạn là như thế,

1. Phiên bản 1 đang được sản xuất
2. Phiên bản 2 đang trong giai đoạn thử nghiệm
3. Phiên bản 3 đang được phát triển
4. Phiên bản 4 đang trong kế hoạch.

Và còn có các cầu giao tiếp Ứng dụng chéo khác, một số tác vụ theo lịch trình, một số tích hợp của bên thứ ba, dịch vụ web cho một số thiết bị giao tiếp khác nhau như điện thoại di động, v.v.

Cuối cùng, Code First sử dụng ObjectContext của Entity Model, EF cũ hơn tạo EDMX và sử dụng ObjectContext với EntityObject là thực sự đủ cho mọi thứ. Bạn có thể dễ dàng tùy chỉnh mẫu văn bản để tạo mã. Phương pháp phát hiện thay đổi chậm hơn khi triển khai ObjectContext, nhưng thay vì tạo proxy, nhóm EF có thể dễ dàng cải thiện tốc độ Phát hiện thay đổi thay vì phát minh lại mã trước tiên.

Di chuyển tự động

Di chuyển tự động nghe có vẻ tốt về lý thuyết, nhưng không thể trong thực tế một khi bạn đi vào hoạt động. Nó chỉ tốt cho tạo mẫu, phát triển một số bản demo nhanh.

Code First Migration hoàn toàn không phù hợp trong hệ thống như vậy. Phiên bản 1 và Phiên bản 2 rất có thể nói chuyện với cùng một cơ sở dữ liệu. Phiên bản 3 và Phiên bản 4 thường được dàn dựng và có cơ sở dữ liệu khác nhau.

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

Cơ sở dữ liệu Đầu tiên là cách tiếp cận thực tế, thật dễ dàng để so sánh và trực quan hóa và duy trì các tập lệnh SQL. DBA có thể làm việc dễ dàng.

Mẫu văn bản

Chúng tôi đã tạo Mẫu văn bản của riêng mình để truy vấn và tạo EDMX và ObjectContext với ít triển khai tùy chỉnh nhằm giải quyết các vấn đề về hiệu suất. Có nhiều ứng dụng với nhiều phiên bản giao tiếp với cùng một cơ sở dữ liệu mà không gặp vấn đề gì.

Đối với tôi, nhấp chuột phải vào tệp .tt và nhấp vào "Chạy Công cụ tùy chỉnh" là bước nhanh nhất và dễ nhất sau đó viết các lớp, định cấu hình và tạo mô hình.

Thông thường đối với các dự án lớn, cơ sở dữ liệu đã được tạo. Hoặc bởi vì đó là cơ sở dữ liệu kế thừa hoặc được tạo bởi một dba có thẩm quyền về hiệu suất. Lợi ích duy nhất từ ​​CodeFirst là nếu bạn không muốn sử dụng các thực thể của EF mà thay vào đó là POCO.

Nghe có vẻ như "Code First" có nghĩa là sử dụng EF với "nhanh nhẹn" hơn (không hiểu quá nhiều về thuật ngữ đó, tôi không nhất thiết có nghĩa là phương pháp luận) và các ứng dụng của Greenfield, nơi bạn không có mô hình dữ liệu hiện có hoặc dữ liệu hiện có; loại ứng dụng mà bạn cũng có thể sử dụng Django hoặc khung PHP hoặc Rails để tuân theo các nguyên tắc của các khung đó thường liên quan đến việc tạo mô hình dữ liệu như một phần của mã, thay vì xây dựng một ứng dụng xung quanh mô hình dữ liệu truyền thống Microsoft xử lý mọi thứ.

Vì vậy, để trả lời câu hỏi tôi sẽ nói không; nếu bạn đã có dữ liệu hiện có và bạn đang tạo một ứng dụng để xử lý nó, Code First sẽ không có ý nghĩa nhiều như vậy. Tuy nhiên, và tôi đã không sử dụng EF rất nhiều, chứ đừng nói gì đến Code First EF, có vẻ như đó là một cách tiếp cận kết hợp lỏng lẻo hơn với mã luôn có lợi. Giả sử bạn có thể sử dụng Code First và sau đó vẫn trỏ lớp đến một mô hình dữ liệu hiện có (thay vì bị buộc phải tạo mô hình), cách tiếp cận Code First vẫn có thể giúp viết mã được trừu tượng hóa và có thể kiểm tra được mà không cần sử dụng "hành trình" thông thường Entity Framework (tức là các siêu dữ liệu được tạo).

Tôi sẽ nói trong các dự án thực sự lớn, mã đầu tiên không có ý nghĩa.

Trong thực tế, khi dự án trở nên thực sự lớn, bạn thường có một sự tách biệt nghiêm ngặt về mối quan tâm. Bạn không thể có cùng một người viết mã C #, thiết kế cơ sở dữ liệu, viết HTML / CSS và thiết kế trực quan trong Photoshop. Thay vào đó, thiết kế cơ sở dữ liệu được thực hiện bởi một quản trị viên cơ sở dữ liệu (hoặc ít nhất là bởi một người tận tâm biết công việc của cô ấy).

Vì cơ sở dữ liệu được thiết kế bởi một người quen thuộc với cơ sở dữ liệu, SQL và các công cụ quản trị và thiết kế cơ sở dữ liệu, nên sẽ rất lạ khi thấy người này sử dụng Entity Framework.

Hơn nữa, tôi không chắc liệu Entity Framework có đủ mạnh để thiết kế cơ sở dữ liệu đúng cách hay không. Còn chỉ số thì sao? Những ràng buộc? Lượt xem?

Mã đầu tiên khả thi đối với các hệ thống lớn: Chỉ cần kiểm tra mô hình sau khi tạo và ánh xạ lại bằng api trôi chảy cho đến khi bạn đạt được mô hình db mà bạn thích.