Phần mềm ưu tiên hướng database first hay code first

Trong ASP.NET có 2 hướng để thiết kế

  • database first: thiết kế database trước rồi mới code sau.
  • code first: Dùng ORM như entity framework hoặc hibernate đối với java để tạo quan hệ giữa các entity bằng việc config những class model trên code, chỉ xem database là nơi chứa dữ liệu thôi.

Em nghĩ các phần mềm khác cũng tương tự, cho em hỏi khi build from cratch một app bất kỳ anh chị thường tạo bảng trong db trước hay tạo quan hệ giữa các class rồi sau đó cho migration với database sau?

Em cảm ơn

Bạn áp dụng loại nào cũng được. Code first được cái là dễ quản lý theo migration. Với lại nếu cần làm prj nhanh thì nên dùng db first. :slight_smile: Thường học ở trường là học theo hướng db first không à, code first tự ngâm cứu.

1 Like

Trường mình thì bắt làm bài tập theo hướng code first mới chịu.

1 Like

mục đích cuối cùng là làm ra được sản phẩm đáp ứng yêu cầu

4 Likes
  • Database first
  • Code first

0 voters

3-4 năm về trước đã có nhiều tutorial về code first .net framework rồi, sau này lên .net core thì code first cũng bá thêm. Bạn có thể lên mạng xem, mình nhớ là có TEDU đó, chuyên tutorial về .net… Bạn tham khảo bên đó để tìm hiểu thêm. Thật ra, dùng cả hai hình thức này đều như nhau, bạn cũng cần phải xác định cấu trúc cơ bản của db mà bạn muốn dùng gồm những gì, rồi phát triển lên thêm thôi.
Trường yêu cầu kiểu gì mình chơi kiểu đó, hồi xưa 2013 lúc mình còn học thì trường chỉ dạy db first thôi, không được học mvc nữa, còn lại sinh viên tự cày. :smiley:

3 Likes

Sao database first lại nhiều thế nhỉ, mình kỳ vọng code first phải chiếm đa số hơn. Nhưng không gian mẫu mới có 11 lựa chọn chắc chưa khách quan lắm :unamused::flushed:

Cái này m nghĩ không chỉ đúng với .NET mà có thể áp dụng cho software development.
Tuỳ thuộc vào trình độ từng lập trình viên và cấu trúc của dự án mà có thể có cách tiếp cận khác nhau. Ví dụ:

  • Entry level: có thể bắt đầu từ DB. Xây dựng code dựa trên liên kết DB có sẵn
  • Mid level: Xây dựng cấu trúc dựa trên Model, sau đó reflect lên DB khi có thay đổi có thể sử dụng migration
  • Senior, SA: với những dự án phức tạp, nhiều logic thì rất khó bắt đầu bởi code hay DB, thường sẽ định hình business rules rồi sẽ phân tích architecture và đầu code.

Việc code và DB là quá trình diễn ra liên tục, khi có sự thay đổi về business thì phải cập nhất code&DB, lúc đó bắt đầu bởi gì thì còn tuỳ thuộc vào từng case.

Lý do mà Entry/Mid levels có thể bắt đầu bởi code/DB cho những dự án nhỏ bởi vì thường các bạn sẽ áp dụng những pattern đơn giản hơn: MVC, MVVM, MVP… trong đó Model (code) và DB phải tới 90% là tương đồng do đó bắt đầu bởi code hay DB không có quá nhiều khác biệt.

Lớn hơn, với những dự án “enterprise” thì MV(X) (nói chung) hiếm được sử dụng, có thể sử dụng các architecture phù hợp hơn, ví dụ: Onion, Hexagonal, etc. lúc đó domain (model) mới là phần cần thiết kế đầu tiên, code sẽ được thực hiện sau và DB chỉ là 1 adapter thôi.

3 Likes

quyết định ở bạn lựa chọn phương pháp nào thôi, trong câu hỏi của bạn không rõ hiện tại đang đi học hay đi làm, nếu còn đi học và muốn áp dụng cái mới để thử sức thì cứ chọn code first :slight_smile: trải nghiệm cho biết cũng là điều hay.

1 Like

Tớ không rõ tớ có hiểu nhầm cậu không, cơ mà hình như cậu muốn hỏi việc cài đặt nhiều hơn là thiết kế.

Với một app (tớ sẽ không nói tới TH cậu cần thiết kế/cài đặt một yêu cầu rất phức tạp như “xây dựng youtube”, khi đó cậu chắc chắn cần dành rất nhiều thời gian để thiết kế), trừ khi cậu có yêu cầu rất đơn giản và straighforward tới mức cậu đã nhìn ra hết tất cả domain, còn không:

  • Cậu cần thiết kế domain của hệ thống trước.
    Đây không phải thiết kế database schema. Cậu cần mô hình hoá domain, biết quan hệ giữa các entity trong domain.
  • Sau đó, từ thiết kế trên, cậu có thể lựa chọn, hoặc là thiết kế database schema và cài đặt nó, hoặc cài đặt domain layer trong application của cậu. Domain model của cậu không nhất thiết phải giống y xì database schema, bởi vì database schema quan tâm tới việc tổ chức dữ liệu sao cho giảm dư thừa, tăng hiệu suất, còn domain model của cậu quan tâm tới việc thể hiện sự liên kết dữ liệu để thực hiện logic trên đó - nếu cậu sử dụng OOP :sweat_smile:
    Giữa domain layer ở application và database sẽ có một layer để convert dữ liệu từ database <-> domain object (nơi ORM của cậu toả sáng :sweat_smile: ).

Tớ nghĩ câu hỏi của cậu muốn hỏi nên viết domain layer trước, hay thiết kế database schema và cài đặt nó trước, sau khi cậu đã thiết kế xong domain.
Câu trả lời thì vẫn là “tuỳ cậu thôi” :smile: Cả 2 cách đều ổn, bởi vì cậu nên có cái nhìn rõ ràng sau khi thiết kế domain rồi. Thậm chí, cậu hoàn toàn có thể cài đặt song song, cả logic ở app lẫn xây dựng database schema, và kết nối chúng với nhau sau.

Hi vọng tớ hiểu đúng ý cậu :smile:

2 Likes

Câu trả lời hay.

Trong SDLC (software development life cycle) thì giai đoạn Design đứng trước giai đoạn Implement. Nên luôn luôn phải phân tích và thiết kế trước, sau khi được team hoặc senior review ok thì mới được làm.

4 Likes

Ví dụ trường hợp khách đưa username password, IP của một database có sẵn gọi là A và thuê mình code phần backend và frontend còn lại thì mình tạo class entity tương ứng để mapping với table trong database có sẵn hay vẫn theo hướng code first nghĩa là là tạo scheme trên code và connect với một database B rỗng, sau đó chuyển dữ liệu từ A sang B ? Em cảm ơn!

Nào nào, cậu được thuê để giải quyết vấn đề, chứ không phải là để máy móc đi theo process :smile:
Để giải quyết vấn đề, bao giờ cũng đi từ những thứ cậu đã có để đi tới mục tiêu. Nếu như họ đưa cậu bát cơm và nhờ cậu tạo đôi đũa để ăn được bát cơm, cậu không nhất thiết phải tạo lại bát cơm rỗng mới, tạo đôi đũa, và migrate cơm từ bát cũ sang bát mới :smile:

Hope it helps!

1 Like
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?