Mã-Đầu tiên hoặc Cơ sở dữ liệu-Trước tiên, cách chọn?

Question

Giả sử chúng ta sẽ bắt đầu dự án mới - ứng dụng có chứa một số logic nghiệp vụ, giao diện người dùng trên ASP.NET, WPF hoặc cả hai. Chúng tôi muốn sử dụng trình tạo mã ORM hoặc DAL và triển khai logic nghiệp vụ của chúng tôi trong các lớp .NET. Có một số cách cơ bản như thế nào chúng ta có thể thể hiện ý tưởng của chúng ta về lĩnh vực kinh doanh:

• Thực hiện các lớp học kinh doanh trên NET và để cho ORM tạo giản đồ cơ sở dữ liệu thích hợp
• Tạo giản đồ cơ sở dữ liệu bằng tay và tạo ra các lớp .NET bởi bộ tạo mã
• Sử dụng một số loại thiết kế trực quan, có thể tạo ra các lớp học kinh doanh và cơ cấu sở dữ liệu hoặc kịch bản

gì làm bạn muốn viết: "Tạo Bảng Người (...)" hoặc "public class Person {.. .} "?
Ưu và khuyết điểm của những cách đó là gì?
Có thể có một số tình huống đặc biệt trong đó một cách tốt hơn cách khác?
Cách chọn cách tối ưu trong một dự án cụ thể?

Tôi khá quen thuộc với cách "Code-First" (hoặc "Model-First"), nhưng dường như hầu hết các ORM được thiết kế như trình tạo mã hoặc trình lập bản đồ, giả sử rằng tôi sẽ triển khai cả cấu trúc cơ sở dữ liệu và doanh nghiệp theo cách thủ công các lớp học.

Câu trả lời dựa trên thời gian hết hạn và các ví dụ về ORM đặc biệt được chào đón.

Chỉnh sửa: Lưu ý, câu hỏi không phải là "Tôi nên làm gì trước khi bắt đầu dự án mới?", Nhưng "Điều gì sẽ được tự động khai báo/tạo tự động, lớp miền hoặc cấu trúc cơ sở dữ liệu?"

Answer 1

Tôi nghĩ rằng cách tiếp cận thích hợp để phân tích và thiết kế hệ thống là bắt đầu bằng cách lập mô hình đối tượng của bạn và mối quan hệ giữa chúng trước tiên. Nếu bạn đang tạo một hệ thống thư viện, bạn nên nghĩ đến các cụm từ Sách, Tác giả, Nhà xuất bản, ISBN làm đối tượng không phải là bảng hoặc thuộc tính cơ sở dữ liệu. Tôi tin rằng đây là cách nó nên được. Điều đó đã được nói, chúng ta hãy thừa nhận rằng các trình tạo mã tiết kiệm rất nhiều thời gian và những người yêu cầu một cơ sở dữ liệu quan hệ để tạo ra mô hình và ánh xạ nó tới các đối tượng DB. Tôi nghĩ đây là lý do chính khiến các nhà phát triển có xu hướng bắt đầu bằng D.B. Điều có thể chứng minh quan điểm của tôi hơn là các nhà phát triển mã đang cố gắng đảo ngược hoạt động hiện đang được triển khai (tức là bạn cung cấp một mô hình và các đối tượng nghiệp vụ và máy phát tạo ra DB với lược đồ thích hợp cho việc này).

Edit:
Dưới đây là một ví dụ về domain-first generators (ADO.NET Entity Framework itself) Model First:

Visual Studio 2010 có khả năng để tạo ra một DDL và tạo ra một cơ sở dữ liệu để lưu trữ các mô hình dữ liệu thực thể. Nhà phát triển có toàn quyền kiểm soát toàn bộ quá trình có thể tùy chỉnh DDL hoặc chọn cơ sở dữ liệu mà anh ta mong muốn hoặc tinh chỉnh quy trình ánh xạ.

Answer 2

Phân tích yêu cầu trước, sau đó là một số tài liệu về những nhu cầu đó và tổng quan về khía cạnh dữ liệu của điều này? Sau đó, bạn biết dữ liệu nào bạn sẽ chụp và cách dữ liệu liên quan đến dữ liệu khác và có thể thiết kế lược đồ cơ sở dữ liệu hoặc cấu trúc dữ liệu để khớp với nó (như đối tượng logic/bảng của nội dung liên quan chứ không phải "tab1_data", " tab2_data "khớp với quá trình thu thập dữ liệu có thể thay đổi, nhưng bạn biết điều đó!).Bạn thậm chí có thể thiết kế một tệp .xsd trước và tạo mã và lược đồ cơ sở dữ liệu từ đó. Đó là tất cả niềm vui và trò chơi những ngày này, tùy thuộc vào skillset của bạn.

Khi lược đồ cơ sở dữ liệu trong tâm trí lưu trữ dữ liệu và đó là điều quan trọng đối với doanh nghiệp, tôi sẽ thiết kế rằng nhiều công cụ đầu tiên có thể truy cập kịp thời, có thể hệ thống gốc sẽ bị thay thế dòng (ví dụ: di chuyển sang các công cụ/ngôn ngữ/giao diện mới hơn). Nếu bạn không biết gì về lý thuyết cơ sở dữ liệu, thì có lẽ đó không phải là lựa chọn tốt nhất của bạn nhưng tôi vẫn sẽ nhận được bất kỳ lược đồ được tạo nào được xác minh bởi người khác.

Answer 3

Tại sao không phải là giao diện đầu tiên?

Quá nhiều ứng dụng bắt đầu với tâm lý chương trình đầu tiên. Đó là một ý tưởng tồi. Lập trình là thành phần nặng nhất của việc xây dựng một ứng dụng, có nghĩa là nó là đắt nhất và khó khăn nhất để thay đổi. Thay vào đó, bắt đầu bằng cách thiết kế đầu tiên.

Thiết kế tương đối nhẹ. Một bản phác thảo giấy rẻ và dễ thay đổi. thiết kế html vẫn tương đối đơn giản để sửa đổi (hoặc ném ra). Điều đó không đúng với lập trình. Thiết kế đầu tiên giúp bạn linh hoạt. Lập trình hàng rào đầu tiên bạn vào và thiết lập bạn với chi phí bổ sung.

Đây là từ Chapter 9 của Getting Real bởi 37signals.

Answer 4

Bắt đầu bằng cách không trực tiếp suy nghĩ về một trong hai, thay vì "mô hình" (tốt nhất là trên giấy) những phần nào ứng dụng của bạn sẽ có từ quan điểm của người dùng.

Nếu bạn có một hình ảnh tinh thần rõ ràng về mô hình đó, Bạn có thể chia các phần thành các phần tử thông thường và cụ thể mà bạn có thể dịch sang cả định nghĩa đối tượng và bảng cơ sở dữ liệu.

Tôi tìm thấy phương pháp này để giảm thời gian chuẩn hóa cơ sở dữ liệu và nỗ lực đáng kể.

Answer 5

Theo ý kiến ​​của tôi không có câu trả lời đúng cho điều này. Tôi đoán nó chủ yếu là do sở thích cá nhân hoặc nhóm của bạn. Tất cả các phương pháp được đề cập (cơ sở dữ liệu đầu tiên, mã đầu tiên, giao diện đầu tiên) có những ưu điểm và nhược điểm riêng của chúng.

Tôi có thể ngồi xuống bằng bút và giấy và phác thảo cấu trúc chung và các chức năng chính của ứng dụng trước khi tôi làm bất cứ điều gì cụ thể, có thể là mã hoặc bảng cơ sở dữ liệu. Một bản vẽ đơn giản của giao diện người dùng cơ bản cũng giúp ích rất nhiều.

Answer 6

“Chỉ cho tôi các sơ đồ của bạn và che giấu các bảng của bạn, và tôi sẽ tiếp tục bị hoang mang. Cho tôi xem các bảng của bạn và tôi thường không cần các sơ đồ của bạn; họ sẽ được rõ ràng “

- Fred Brooks trong‘ The Mythical Man-Month’

Answer 7

Trong hầu hết các trường hợp nó sẽ không quan trọng nhiều. Nó là tùy thuộc vào sở thích cá nhân và kỹ năng hơn bất cứ thứ gì khác. Hầu hết các ứng dụng sẽ không bị ảnh hưởng nhiều theo bất kỳ cách nào, sử dụng bất kỳ điều gì mà nhóm của bạn cảm thấy thoải mái. Trường hợp sự lựa chọn thực sự quan trọng nó phải được rõ ràng mà phương pháp tiếp cận để đi cho.

Điều đó nói rằng, ý kiến ​​cá nhân của tôi là "cơ sở dữ liệu đầu tiên" thường là lựa chọn an toàn hơn. Nếu dữ liệu theo bất kỳ cách nào quan trọng, đặc biệt nếu dữ liệu quan trọng bên ngoài phạm vi ứng dụng cụ thể của bạn, bạn muốn có toàn quyền kiểm soát cách dữ liệu được lưu trữ.

"Mã đầu tiên" (ngụ ý: để cơ sở dữ liệu trong tay của một số công cụ tự động) trong tâm trí của tôi thực sự là một phím tắt, một trong những bạn nên sử dụng khi (và chỉ khi) bạn biết chắc chắn bạn có thể lấy đi với nó .

Answer 8

Để trả lời câu hỏi đã chỉnh sửa của bạn (các lớp tự động db/các lớp thủ công/db), tôi sẽ chọn "không". Mã được tạo tự động của cả hai loại phải tránh vì một số lý do, trước hết là YAGNI. Bạn kết thúc với mã mà bạn chưa từng viết nhưng dù sao bạn cũng không chịu trách nhiệm, mã bạn sẽ không bao giờ sử dụng, và (theo kinh nghiệm của tôi) mã bạn sẽ mất nhiều thời gian để tái cấu trúc hơn là bạn đã tự thiết kế và viết nó trong lần đầu tiên địa điểm. Và cả hai đều giữ cho tập trung của bạn cách xa vị trí quan trọng nhất - Người dùng.

Answer 9

Cá nhân tôi thích kiểm soát việc tạo đối tượng RDBMS. Khi tôi sử dụng mã EF đầu tiên, nó thực sự tạo ra nhiều công việc hơn cho những thứ cơ bản như quan hệ bảng vv mà máy phát mã phong nha nhất cho bạn ra khỏi hộp (tôi biết đó là ý tưởng ... kiểm soát nhiều hơn trên Mô hình của bạn!) . Ngoài ra ý tưởng rằng EFCF sẽ tạo ra db như tôi hy vọng cho là một chút đáng sợ. (theo truyền thống, Code dễ dàng hơn sau đó RDMBS!)

Đối với hệ thống yêu cầu liên tục phát triển (ví dụ: SaaS) và thường là hệ thống cấp doanh nghiệp lớn với 500 + bảng v.v. Mặt khác, nếu bạn có một dự án cơ sở dữ liệu SQL Server 2008 thích hợp với tất cả các bảng, SP, Trình kích hoạt, các chỉ mục được lập kịch bản và bạn có thể triển khai chúng từ Visual Studio, nó sẽ dễ quản lý hơn nhiều. Bây giờ bạn có quyền tự do sử dụng bất kỳ codegen nào bạn muốn cho các bảng của bạn (thậm chí tự xây dựng bảng của bạn)

Bạn không bị ràng buộc vào Khung (EFCF), bạn có thể sử dụng các ORM khác nhau (NHibernet cho ví dụ) tùy thuộc vào 'mini của bạn 'yêu cầu dự án trong hệ thống lớn của bạn.

Answer 10

Có 3 khía cạnh quan trọng mà cần phải được xem xét khi phát triển một ứng dụng cơ sở dữ liệu ...

1. Kinh nghiệm người dùng
2. dữ liệu chất lượng
3. Chi phí để duy trì kinh nghiệm hai (Thành viên đầu tiên, và dữ liệu Chất lượng)

Tôi tin rằng ưu tiên của ba mục này được thể hiện theo thứ tự chúng được trình bày, có nghĩa là ưu tiên cao nhất là Trải nghiệm người dùng, p cao thứ hai riority là chất lượng dữ liệu, và thứ ba là chi phí để làm như vậy. Tất nhiên những điều này có thể được tranh luận, nhưng khái niệm về mã đầu tiên hoặc cơ sở dữ liệu trước tiên liên quan đến ưu tiên thứ ba - chi phí. Bất kể sự lựa chọn là gì - trước hết là mã hoặc cơ sở dữ liệu, hãy đảm bảo hai ưu tiên đầu tiên được hoàn thành ...