M trong MVC ở đâu?

Tôi đang cố gắng cấu trúc lại ứng dụng của mình thành MVC, nhưng tôi bị kẹt ở phần M.

Trong một ứng dụng dựa trên cơ sở dữ liệu, mô hình được triển khai trong mã ứng dụng, phải không?

Nhưng sau đó, những gì trong cơ sở dữ liệu - đó không phải là mô hình?

(Tôi không sử dụng cơ sở dữ liệu như một kho lưu trữ đối tượng đơn giản - dữ liệu trong DB là tài sản doanh nghiệp).

Phải, cả mô hình trong mã và cơ sở dữ liệu đều là "Mô hình".

Mô hình phải thực hiện với những gì ứng dụng của bạn "IS" và bộ điều khiển là những gì nó "làm". Bất kỳ mã nào liên quan đến sự kiên trì trực tiếp đến cơ sở dữ liệu đều được coi là Mô hình.

Lưu ý: MVC là một mẫu , vì vậy đừng nghĩ quá nhiều. Thật dễ dàng để có được tất cả các siêu thực hiện MVC đúng cách, nhưng vào cuối ngày, đó chỉ là một suy nghĩ! Nó có nghĩa là giữ logic kinh doanh của bạn ra khỏi cơ sở dữ liệu và giao diện người dùng - đó là nó. Trước MVC, mọi người sẽ đưa logic kinh doanh lên tất cả trong các trang web của họ khi có trên máy chủ hoặc họ sẽ có một loạt các tập lệnh bắn vào cơ sở dữ liệu thực hiện logic nghiệp vụ cùng với mã bền vững. MVC được đưa ra để khiến mọi người bắt đầu suy nghĩ theo cách giúp làm cho mã của họ có thể sử dụng lại, vì vậy đừng bị cuốn vào các chi tiết quá nhiều.

Trygve Reenskaug đã viết các bài báo ban đầu mô tả mô hình MVC vào năm 1978. Mô hình trong mô tả của ông là mô hình đối tượng đại diện cho các đối tượng, hiện tượng và khái niệm trong thế giới thực. Trong kịch bản của bạn về một ứng dụng được hỗ trợ cơ sở dữ liệu, mô hình là hình chiếu của dữ liệu của bạn. Nói một cách đơn giản, mô hình là các lớp và các mối quan hệ của chúng mà ứng dụng của bạn quan tâm.

Trong thực tế, thường có hai mô hình được sử dụng trong MVC, Mô hình miền (ánh xạ vào cơ sở dữ liệu của bạn) và Mô hình ứng dụng (còn được gọi là Mô hình xem theo thuật ngữ ngày nay). Mô hình ứng dụng là hình chiếu của Mô hình miền cũng chứa dữ liệu cụ thể của chế độ xem để hiển thị chế độ xem. Cách tiếp cận này được gọi là MMVC . Bộ điều khiển tương tác trực tiếp với mô hình miền và đưa ra một mô hình ứng dụng cho khung nhìn. Trong mẫu MVVM, Mô hình ứng dụng và Trình điều khiển được kết hợp.

1. Bạn không cần một cơ sở dữ liệu cho MVC. Nếu mô hình của bạn tình cờ nói chuyện với cơ sở dữ liệu, thì thật tuyệt. Nó cũng có thể tự tồn tại trong một tệp phẳng hoặc hoàn toàn không tồn tại.

2. Mô hình là nơi dữ liệu được lưu trữ trong bộ nhớ trong ứng dụng của bạn. Bạn cũng sẽ muốn sử dụng mô hình để thực hiện các tính toán và xác nhận dữ liệu của nó. Ví dụ: bạn có mô hình FinancePayment, với các thuộc tính như lãi suất, thời hạn và nguyên tắc. Bạn có thể thêm phương thức getMonthlyPayment () vào mô hình của mình để tính toán khoản thanh toán hàng tháng. Bạn sẽ không muốn làm điều đó trong bộ điều khiển hoặc chế độ xem.

3. Chế độ xem nên bị câm một cách hợp lý, hoàn toàn không có logic hoặc chỉ sử dụng ràng buộc dữ liệu đơn giản (xem các mẫu Điều khiển thụ động và Giám sát trên trang web của Martin Fowler ). Chế độ xem tăng các sự kiện khi người dùng thực hiện công cụ, như nhấp vào nút.

4. Bộ điều khiển chịu trách nhiệm xử lý các sự kiện (chạy một số mã khi người dùng nhấp vào nút lưu) và để thiết lập các thuộc tính mô hình và yêu cầu mô hình tải và tự lưu (nếu sử dụng kiên trì). Bộ điều khiển không nên thực hiện tính toán trên dữ liệu của mô hình. Tuy nhiên, trong bộ điều khiển, bạn có thể thực hiện một số tính toán thay mặt cho chế độ xem, chẳng hạn như "if model.profit () <0 sau đó widget.colour = 'red'"

5. Bạn sẽ có thể chuyển sang phiên bản dòng lệnh của ứng dụng mà không thay đổi mô hình và không làm mất chức năng của các mô hình.

a. Bạn có thể có thể chuyển sang phiên bản di động của ứng dụng của mình (trái ngược với phiên bản dành cho máy tính để bàn) bằng cách chỉ chuyển đổi chế độ xem (chứ không phải bộ điều khiển hoặc kiểu máy). Bạn sẽ có thể kiểm tra đơn vị các mô hình và bộ điều khiển của mình mà không cần khung kiểm tra GUI.

Mô hình là mã có kết nối với V và C ở lối vào và lưu trữ liên tục (có thể là bất cứ thứ gì từ tệp đến cơ sở dữ liệu SQL / NoQuery) trong phần phụ trợ. Đó không chỉ là mã tải từ db và lưu trữ sang db (đó là một trong những hiểu lầm của mô hình), đó là mã thực sự làm tất cả các "miền" hoạt động - chọn, lọc, thay đổi, tính toán, quyết định dữ liệu. Bao gồm tất cả logic phi UI của ứng dụng.

Lấy một cái nhìn rất đơn giản và duy tâm.

Mô hình thường được xem như là một mô hình của miền (đại khái là doanh nghiệp), không phải là một mô hình của dữ liệu. Chúng có thể trông tương tự nhau, nhưng chúng không hoàn toàn gắn liền với nhau.

Chế độ xem phải là mô hình của giao diện người dùng ứng dụng và Trình điều khiển phải là mô hình của luồng từ chế độ xem này sang chế độ xem khác.

Logic nghiệp vụ phải được gói gọn hoàn toàn trong Mô hình, cho dù đó là trong cơ sở dữ liệu hay mã. Mặc dù một số logic nghiệp vụ có thể được lặp lại trong Chế độ xem hoặc Bộ điều khiển, vì nhiều lý do, có thể (và an toàn) có thể loại bỏ hoàn toàn hai thành phần đó và đặt một giao diện người dùng khác vào vị trí của nó.

Theo hiểu biết của tôi, MVC chỉ là mô tả về mẫu kiến ​​trúc của ứng dụng khách của bạn. Hình ảnh ở đây trong Wikipedia chỉ cho thấy điều này:

http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93 điều khiển

Tất nhiên, khi bạn có các phần của ứng dụng được triển khai trong "các thủ tục được lưu trữ", thì các mã cơ sở dữ liệu đó cũng có thể là một phần của mô hình hoặc thậm chí của bộ điều khiển (tùy thuộc vào mã làm gì). Nhưng nếu đó không phải là trường hợp, thì cơ sở dữ liệu rõ ràng là "bên ngoài MVC", giống như bạn đã nêu.

But then, what is in the database -- is that not also the model?

Không có nó không phải là. " Mô hình quản lý hành vi và dữ liệu của miền ứng dụng". Thông thường, Model móc vào một cơ sở dữ liệu có, nhưng không phải là một yêu cầu. Mô hình là một lớp mới giữa ứng dụng của bạn và cơ sở dữ liệu. Phần cuối có thể là một tập hợp các đối tượng Mock, XML hoặc bất kỳ thứ gì khác hỗ trợ tính bền vững của dữ liệu.

Bằng cách tách riêng các lớp, bạn có cho mình sự linh hoạt cao hơn nhiều để sử dụng các thực tiễn kiểm tra đơn vị tốt hơn, làm cho mã dễ quản lý hơn (EG SQL được thay thế bởi Oracle) trong số các lợi ích khác.

Điều tương tự cũng xảy ra với bộ điều khiển. MVC định nghĩa bộ điều khiển là người trung gian giữa hai lớp. Không có "lớp nghiệp vụ" được định nghĩa trong MVC. Thay vào đó, bạn thêm của riêng bạn. MVC không gói gọn tất cả các lớp cần thiết để xây dựng hầu hết các ứng dụng. Nó chỉ là một hướng dẫn chung cho cấu trúc cơ bản.

Những sự tách biệt này là chìa khóa để cho phép đảo ngược điều khiển hoạt động.

Cơ sở dữ liệu là một chi tiết thực hiện của mô hình. Mô hình phải là Mô hình miền đầy đủ và nên kết hợp dữ liệu và quy trình. Sự tách biệt phải là giữa các mối quan tâm khác biệt và không phải giữa một quy trình và dữ liệu liên quan đến quy trình đó.

Xem thêm: http://martinfowler.com/bliki/AnemiaDomainModel.html

Thật ra rất đơn giản, "Model" đại diện cho sự trừu tượng hóa cho giao diện dữ liệu. Đó là lý do tại sao:

• Cơ sở dữ liệu được coi là một phần của Mô hình , nhưng không phải là chính mô hình
• Dữ liệu của Model có thể đến từ cơ sở dữ liệu, tệp, dịch vụ web hoặc thậm chí bị chế giễu.
• Các lớp mô hình trong MVC, HMVC hoặc các khung tương tự sẽ lưu trữ các truy vấn (xem nguyên tắc "mô hình béo, bộ điều khiển mỏng" [ 1 ] [ 2 ] [ 3 ])

Và đối với tôi, chính xác thì đó là lý do tại sao khi ai đó đề cập đến các mô hình bên ngoài bối cảnh MVC, thì ai đó rất có thể đề cập đến cấu trúc của dữ liệu (ví dụ: lược đồ ).

Tôi nghĩ rằng M chứa một số logic và lưu trữ dữ liệu vào DB. Bộ điều khiển gọi mô-đun nào sẽ được thực thi và mô-đun này sẽ thực hiện logic và lưu trữ dữ liệu trong DB (Có thể có lớp liên tục) và sau đó mô-đun này trả về giá trị cho V.

M (odel) trong MVC sẽ nắm bắt mô hình của doanh nghiệp / tên miền ở một nơi duy nhất.

Điều đó lý tưởng bao gồm các quy tắc kinh doanh của tên miền cũng như cấu trúc của nó.

Lý tưởng sholuld C (bộ điều khiển) chỉ quan tâm đến việc trung gian thông tin của mô hình kinh doanh với bản trình bày (ví dụ: Chế độ xem) và nắm bắt đầu vào của người dùng từ V (iew) để bắt đầu thay đổi trạng thái của mô hình.

Lớp cơ sở dữ liệu chỉ xử lý (hay đúng hơn là chỉ nên xử lý) với sự tồn tại của trạng thái của mô hình tại thời điểm cụ thể.

Như vậy nó không phải là cái gì đó thuộc về một trong hai mẫu hoặc điều khiển một phần của mô hình MVC, nhưng đúng hơn đó là một mối quan tâm hoàn toàn tách biệt mà có thể được thực hiện ngầm bằng cách minh bạch kiên trì bất kỳ thay đổi mô hình (như là một chức năng của mặt tiền, cung cấp tương tác với Mô hình của bạn với Bộ điều khiển) hoặc như được thực hiện thường xuyên hơn không, được Bộ điều khiển gọi một cách rõ ràng sau khi hoàn thành việc tạo đột biến cho mô hình.

Mô hình trong một thế giới lý tưởng chỉ nên chứa logic kinh doanh, nó mô hình một số đối tượng thực như Nhà. Tuy nhiên, trong hầu hết các trường hợp, mô hình cần duy trì dữ liệu của nó để lưu trữ.

Tương tác giữa mô hình và dữ liệu được lưu trữ có thể xảy ra trên một lớp dữ liệu riêng biệt hoặc trực tiếp trong mô hình, đó là trường hợp khi sử dụng ORM (Object Relative Mapper). Nói cách khác, mô hình kết nối trực tiếp với cơ sở dữ liệu hoặc mô hình truyền dữ liệu của nó tới một đối tượng "truy cập dữ liệu" khác kết nối với cơ sở dữ liệu.

Một ORM (Object Relation Mapper) ánh xạ các trường trong bảng cơ sở dữ liệu tới các thuộc tính của đối tượng mô hình của bạn, cung cấp getters và setters. Trong trường hợp này không có lớp dữ liệu riêng biệt và mô hình chịu trách nhiệm trực tiếp cho việc lưu giữ dữ liệu của nó.

Dưới đây là một ví dụ về Ruby sử dụng ActiveRecordORM phổ biến:

class House < ActiveRecord::Base
end

house = House.new
house.price = 120000
house.save

Pricelà một trường trong housesbảng được tự động phát hiện bằng cách ActiveRecordthêm getter và setter vào đối tượng. Khi saveđược gọi là giá trị của thuộc tính price được duy trì cho cơ sở dữ liệu.

Theo quan điểm của tôi, chuyên gia có một lớp dữ liệu là bạn có một điểm trong đó bạn có thể thao tác dữ liệu trước khi đưa vào mô hình, mô hình có ít lo lắng hơn, nó có ít trách nhiệm hơn. Ví dụ: bạn có thể cần kết hợp dữ liệu từ một số nguồn dữ liệu không tương thích, đây là điều mà ORM không thể dễ dàng xử lý.

Con chính là một lớp trừu tượng khác để quản lý, nếu bạn không cần nó, đừng bận tâm, hãy giữ nó đơn giản. Ít di chuyển các bộ phận, ít đi sai.

Có bạn đúng.

(Bộ điều khiển xem mô hình)

Một kiến ​​trúc để xây dựng các ứng dụng tách dữ liệu (mô hình) khỏi giao diện người dùng (chế độ xem) và bộ xử lý (bộ điều khiển).

Trong thực tế, các khung nhìn và bộ điều khiển MVC thường được kết hợp thành một đối tượng vì chúng có liên quan chặt chẽ với nhau. Theo MSDN

Bộ điều khiển diễn giải các đầu vào chuột và bàn phím từ người dùng, thông báo cho kiểu máy và / hoặc the view to change as appropriate.

Kiểm tra sơ đồ này:

Ví dụ, mã bộ điều khiển xác nhận yêu cầu dữ liệu và khiến nó được trả về trong một khung nhìn. Các đối tượng điều khiển xem được gắn với chỉ một mô hình; Tuy nhiên,a model can have many view-controller objects associated with it.