Tại sao tôi nên sử dụng mã Entity Frameworkfirst nếu nó không thể được sử dụng trong sản xuất an toàn và những thứ như chỉ mục không thể được mô tả

Question

Tôi mới bắt đầu một dự án web cực lớn và thực sự cố gắng làm mọi thứ đúng.

cụ tôi sử dụng cho đến nay là

• ASP.NET MVC 3
• Entity Framework 4.3
• Ninject 3

Tất cả đang tiến triển tốt, nhưng tôi đang tìm kiếm một vài với Entity Framework CodeFirst một chút sơ sài.

Ví dụ: tôi phải sử dụng http://codefirstmembership.codeplex.com/ để thiết lập thông tin thành viên như một phần của thiết lập mã đầu tiên. Điều này cảm thấy một chút ropey phải sử dụng một cái gì đó bên thứ ba này. Rõ ràng là tôi nên đủ 1337 để "cuộn của riêng tôi" nhưng tôi không muốn cắn quá nhiều từ lúc đi. Chạy aspnet_regsql cảm thấy khủng khiếp, và sẽ bị mất với mỗi bản cập nhật db. Dù sao, tất cả đều làm việc với thư viện ở trên và nó không quá tệ. Giàn giáo dường như đã phá vỡ tuy nhiên.

Bây giờ ngoài tất cả điều này, bây giờ có vẻ như công cụ này sẽ trở thành probamatic khi tôi đang chạy trong môi trường sống. Bất kỳ thay đổi lược đồ nào tôi sẽ muốn thực hiện giữa db dev và db trực tiếp sẽ phải được quản lý thủ công bằng tập lệnh, vì vậy tại thời điểm đó tôi không bị mất điểm mã đầu tiên?

Tôi đã làm việc với Google App Engine trong năm qua và hy vọng mã đầu tiên về cơ bản sẽ hoạt động theo cùng một cách? Tức là, thực hiện thay đổi và họ sửa đổi dữ liệu trực tiếp. Bây giờ tôi giả định, do không thực hiện tái cấu trúc nghiêm trọng trong công cụ ứng dụng, về cơ bản nó không gây hại gì trong sản xuất. Vì vậy, bạn không bao giờ có thể đổi tên một bảng với AppEngine. Nó sẽ luôn tạo một bảng mới, và để lại cái cũ. Bạn sẽ phải chuyển dữ liệu theo cách thủ công.

Vì vậy, tôi hiện đang suy nghĩ. Tại sao không chỉ đi Cơ sở dữ liệu đầu tiên? Tôi đã làm việc với linq2sql trong 3 năm và rất thoải mái với việc đi db đầu tiên. Mặc dù TBH kiểm soát nguồn db của tôi stratergy đã được một chút .... thiếu. Vì vậy, tôi đã hy vọng mã đầu tiên sẽ thực thi tình hình đó để cải thiện, nhưng nó thực sự làm cho tôi cảm thấy rằng tôi nên đi DB đầu tiên, và chỉ là nghiêm ngặt về việc giữ nó dưới sự kiểm soát.

Tôi thực sự đánh giá cao bất kỳ suy nghĩ nào về loại tình huống này và cũng có thể so sánh với việc sử dụng Nhibinate như thế nào?

Answer 1

Kịch bản nâng cấp mà bạn đang mô tả đang được thêm vào trong EF-Migrations. Bản phát hành trực tiếp của tính năng này đã có sẵn và sẽ sớm trở thành phiên bản phát hành được hỗ trợ chính thức.

Check-out: https://blogs.msdn.com/b/adonet/archive/2012/02/09/ef-4-3-automatic-migrations-walkthrough.aspx?Redirected=true

Check-out: http://coding.abel.nu/tag/ef-migrations/

Answer 2

Chỉ mất của tôi về vấn đề này ...

Bạn không cần phải thực hiện một lựa chọn tốt -

bạn có thể sử dụng Seed, trình khởi tạo tùy chỉnh (và di chuyển tay trong tay - với việc di chuyển, bạn có thể thực sự thay đổi chúng theo cách thủ công, ví dụ như thêm chỉ mục ở đó, v.v.) để 'tiêm' SQL thô (và hầu hết các nhu cầu c) sẽ được bao phủ bởi điều đó). Theo tôi biết bạn có thể chạy một bộ tạo biểu mẫu tập tin batch tùy chỉnh (nhưng chưa thử, mặc dù tôi không thấy tại sao không).Di chuyển được thực hiện thông qua PS vì vậy tôi đoán có không gian để tích hợp ở phía đó quá.

Bạn có thể sử dụng cấu hình C# và đồng bộ hóa nhanh - sau đó định hình lại sau - hoặc khi sử dụng cố định một số 'sử dụng trình khởi tạo hiện có' không làm gì từ mã và di chuyển mọi thứ sang phía Db và DBA của bạn.

IMO, bạn có thể đi 'rất xa' theo nghĩa này, trước khi thực sự cần phải tắt CF và chỉ hoạt động từ Db.

Đối với cơ sở dữ liệu lớn hơn hoặc môi trường công ty, chắc chắn đó không phải là công cụ thích hợp cho công việc.

Tôi nghĩ rằng nó bây giờ an toàn cho sản xuất - nhưng phụ thuộc vào những gì bạn xem xét an toàn, vài điều ...

Ngoài ra, EF/CF đã đi một chặng đường dài kể từ khi khởi đầu thực sự - Tôi sử dụng nó kể từ khi bắt đầu - và ban đầu nó có vấn đề lớn. Các phiên bản mới nhất hiện nay khá vững chắc ở tất cả các bên, vì vậy nó đang đạt được điều đó tôi nghĩ.

... ở mặt sau - tôi đã làm việc ra một số kịch bản khá phức tạp với phương pháp tiếp cận mã đầu tiên (EF và ngược lại). Tuy nhiên, một vài điều đã khiến tôi trở lại với EF (trên đầu trang của những gì bạn đã đề cập) ...

Hỗ trợ UDF, lượt xem (với LINQ - như thể bạn không sử dụng LINQ một trong những 'ưu' lớn đã biến mất) - sẽ xuất hiện trong EF 5.0 (tôi không kiểm tra nhưng đó là những gì họ đang khuyến khích) - như đối với các kịch bản phức tạp hơn, bạn cần phải tối ưu hóa ở phía SQL (hoặc để có thể thực hiện các truy vấn tùy chỉnh ở mặt sau và sau đó bản đồ trở lại, tức là linh hoạt hơn về phía đó). Vì vậy, đó là một điều hứa hẹn nếu nó đến (mặc dù sẽ không được hoàn hảo tôi mong đợi). (ở bên cạnh, bạn thực sự có thể chạy các truy vấn tùy chỉnh và sau đó ánh xạ tới các đối tượng của bạn - nhưng loại tác phẩm đó và bạn không thể làm mọi thứ để nó bị hạn chế theo cách)

Thực hiện với các truy vấn và một lần nữa yêu cầu nhiều hơn kịch bản nhiệm vụ - đó là vấn đề chính của tôi với nó. Điều đó cũng hứa hẹn sẽ tốt hơn trong EF 5.0 - vì vậy hãy chờ xem.

Có nói rằng -
ưa thích của tôi là mã tùy chỉnh hoặc mã nguồn mở đầu tiên như giải pháp, ORM - nơi bạn có thể kiểm soát nhiều thứ hơn. Vẫn có nhiều nhà cung cấp hỗ trợ, vv là những gì làm cho 'chính thức' hoặc MS triển khai khả thi hơn về lâu dài.

hy vọng điều này sẽ giúp bất kỳ