Mô hình trên mỗi bảng cơ sở dữ liệu?

Tôi đang sử dụng codeigniter và thấy mình trong một tình huống tương tự khi tôi lặp lại các phương thức Model. Tôi đang tạo Model cho mỗi Trình điều khiển. Nhưng tôi sẽ tạo một Mô hình cho mỗi bảng cơ sở dữ liệu được coi là thực hành tốt? Bằng cách đó, phương pháp không được viết hai lần.

Thay vì Model trên mỗi Bộ điều khiển hoặc Một số Mô hình nhỏ được chia sẻ.

Ví dụ nếu tôi có phương thức mô hình get_user ($ user_id) Tôi có thể viết nó trên users_models.php ...

Một trong những nhược điểm tôi thấy về điều này là tôi có thể phải gọi một số mô hình, thay vì chỉ có tên người dùng_models.php.

Có thể tải một số mô hình trong đó một số phương pháp có thể không được sử dụng từ bộ điều khiển có ảnh hưởng đến hiệu suất và tốc độ không? Điều gì có thể là cách tốt nhất để giải quyết vấn đề này?

Lưu ý: Có câu hỏi tương tự, nhưng chúng không bao gồm mặt bằng của Mô hình trên mỗi bảng cơ sở dữ liệu.

Tôi nói rằng một mô hình trên mỗi bảng chỉ là tạo lại cơ sở dữ liệu của bạn trong cấu trúc lớp. Nó được biết đến như một mô hình thiếu máu và được coi là một mô hình chống. Đó là bởi vì các lớp được dự định có cả dữ liệu và hành vi. Nếu bạn giới hạn các mô hình của mình trong một bảng duy nhất, bạn sẽ đặt mã (hành vi) cần xử lý dữ liệu và hành vi từ nhiều bảng ở đâu? Bộ điều khiển của bạn sau đó sẽ cần các mô hình sử dụng một hoặc nhiều mô hình "bảng" này ... Vì vậy, ngoài các ứng dụng cơ bản nhất, bạn sẽ kiếm được rất ít nếu có bất cứ điều gì từ phương pháp này.

Nói chung, bạn nên tạo các mô hình của mình không phải trên mỗi bảng hoặc mỗi bộ điều khiển mà trên mỗi đối tượng kinh doanh. Đôi khi nó có thể là mối quan hệ 1: 1 với cấu trúc bảng của bạn hoặc với bộ điều khiển của bạn, nhưng không cần thiết.

Trong ví dụ của bạn, bạn có thể có một users_modellớp được gọi từ một số bộ điều khiển. Điều này là tốt và đôi khi thậm chí là mong muốn. Tuy nhiên, trong hầu hết các trường hợp, users_modellớp sẽ lấy dữ liệu từ một số bảng.
Ví dụ, last_login_datethuộc tính của users_modellớp có thể ( không phải ) được lấy từ một user_auditbảng riêng biệt có mối quan hệ một-nhiều với usersbảng chính .

Và tôi sẽ nói nếu bạn có một bảng SQL cho mỗi đối tượng kinh doanh thì rất có thể cấu trúc cơ sở dữ liệu của bạn không được chuẩn hóa.

Tôi hầu như đồng ý với câu trả lời của Dime rằng bạn muốn tạo mô hình cho mỗi đối tượng kinh doanh - những vấn đề mà doanh nghiệp đang cố gắng giải quyết sẽ thúc đẩy cách bạn tạo các lớp mô hình. Trong thực tế, tôi đã thấy rằng việc tạo một mô hình trên mỗi bảng là một nơi tốt để bắt đầu. Một lược đồ được thiết kế đúng có khả năng bắt chước các quy trình kinh doanh mà bạn cần mô hình hóa trong mã ứng dụng - còn được gọi là Mô hình miền.

Sử dụng lớp Ánh xạ đối tượng / quan hệ là hữu ích để Mô hình miền của bạn chứa các mối quan hệ giống như lược đồ cơ sở dữ liệu mà không cần các cuộc gọi lặp lại đến lớp truy cập dữ liệu. Hãy xem Eloquent cho PHP làm ví dụ. Cả lược đồ và Mô hình miền phải được thiết kế để hỗ trợ các quy trình nghiệp vụ.

Điều này dẫn đến phần đầu tiên trong câu trả lời của Marjan Venema:

Tôi nói rằng một mô hình trên mỗi bảng chỉ là tạo lại cơ sở dữ liệu của bạn trong cấu trúc lớp. Nó được biết đến như một mô hình thiếu máu và được coi là một mô hình chống.

Một mô hình miền thiếu máu là một mô hình chống. Một "mô hình trên mỗi bảng" như Venema gợi ý có thể được xem là "tái tạo cơ sở dữ liệu của bạn", tuy nhiên hoàn toàn không đúng khi nói đây là Mô hình miền thiếu máu.

Từ Martin Fowler:

Triệu chứng cơ bản của Mô hình miền thiếu máu là ở lần đầu tiên, nó trông giống như thật. Có các đối tượng, nhiều tên được đặt theo danh từ trong không gian miền và các đối tượng này được kết nối với các mối quan hệ và cấu trúc phong phú mà các mô hình miền thực có. Nắm bắt được khi bạn nhìn vào hành vi và bạn nhận ra rằng hầu như không có bất kỳ hành vi nào trên các đối tượng này, khiến chúng trở nên nhỏ hơn các túi getters và setters.

(nhấn mạnh, của tôi)

Yếu tố chính trong mô hình miền thiếu máu là thiếu hành vi hoặc phương thức trên các lớp Mô hình miền.

Đó là bởi vì các lớp được dự định có cả dữ liệu và hành vi. Nếu bạn giới hạn các mô hình của mình trong một bảng duy nhất, bạn sẽ đặt mã (hành vi) cần xử lý dữ liệu và hành vi từ nhiều bảng ở đâu?

Một lần nữa, bạn có thể và nên đặt hành vi trong Mô hình miền của mình, ngay cả khi chúng chỉ ánh xạ tới một bảng. Hành vi ảnh hưởng đến nhiều bảng thực sự ảnh hưởng đến nhiều đối tượng xảy ra để ánh xạ tới nhiều bảng. Domain Driven Design là một cách tiếp cận chính xác cho cùng một vấn đề mà Venema đã đề cập: "bạn đặt mã (hành vi) cần xử lý dữ liệu và hành vi từ nhiều bảng ở đâu?"

Và câu trả lời là một gốc tổng hợp . Martin Fowler tuyên bố:

Uẩn là một mẫu trong Thiết kế hướng tên miền. Tập hợp DDD là một cụm các đối tượng miền có thể được coi là một đơn vị. Một ví dụ có thể là một đơn hàng và các chi tiết đơn hàng của nó, đây sẽ là các đối tượng riêng biệt, nhưng thật hữu ích khi coi đơn hàng (cùng với các chi tiết đơn hàng của nó) dưới dạng một tổng hợp.

(nhấn mạnh, của tôi)

Một "cụm đối tượng miền" cũng có thể được xem là "Mô hình miền ánh xạ tới nhiều bảng." Hành vi ảnh hưởng đến nhiều bảng nên được xác định trên Root tổng hợp - Một lớp đóng gói "điều" ảnh hưởng đến nhiều bảng hoặc đối tượng:

Một lần nữa, từ Martin Fowler:

Một tập hợp thường sẽ chứa các bộ sưu tập mutlipl, cùng với các trường đơn giản.

Để trả lời câu hỏi ban đầu của OP:

... việc tạo một Mô hình trên mỗi bảng cơ sở dữ liệu có được coi là thực hành tốt không? Bằng cách đó, phương pháp không được viết hai lần.

Tôi muốn nói rằng đây là một nơi tốt để bắt đầu, nhưng lưu ý rằng lược đồ và mô hình đối tượng của bạn không phải khớp 100%. Mô hình đối tượng nên được quan tâm nhiều hơn với việc thực hiện và thực thi các quy tắc kinh doanh. Lược đồ nên tập trung hơn vào việc lưu trữ dữ liệu kinh doanh theo cách mô đun và có thể mở rộng.

Một mô hình trên mỗi bộ điều khiển sẽ không được thực hành tốt, mặc dù có một biến thể của mô hình được gọi là Mô hình xem phù hợp với lớp Trình điều khiển. Một Xem Mẫu là một tổ chức lại mô hình tên miền để phù hợp với một loại nhất định của màn hình, có thể là một trang web hoặc hình thức trong một ứng dụng GUI.