MVC là gì, thực sự?

Là một lập trình viên nghiêm túc, làm thế nào để bạn trả lời câu hỏi MVC là gì?

Trong suy nghĩ của tôi, MVC là một chủ đề mơ hồ - và vì thế, nếu khán giả của bạn là người học, thì bạn có thể tự do mô tả nó theo các thuật ngữ chung khó có thể gây tranh cãi.

Tuy nhiên, nếu bạn đang nói chuyện với một đối tượng am hiểu, đặc biệt là một người phỏng vấn, tôi có một thời gian khó khăn để nghĩ ra một hướng đi mà không có nguy cơ phản ứng "cũng không đúng! ...". Tất cả chúng ta đều có trải nghiệm thực tế khác nhau và tôi thực sự đã gặp mô hình triển khai MVC tương tự hai lần.

Cụ thể, dường như có những bất đồng liên quan đến sự nghiêm ngặt, định nghĩa thành phần, tách các bộ phận (phần nào phù hợp với nơi nào), v.v.

Vì vậy, làm thế nào tôi nên giải thích MVC theo cách chính xác, ngắn gọn và không gây tranh cãi?

MVC là một kiến ​​trúc phần mềm - cấu trúc của hệ thống - phân tách logic miền / ứng dụng / doanh nghiệp (bất cứ điều gì bạn thích) với phần còn lại của giao diện người dùng. Nó thực hiện điều này bằng cách tách ứng dụng thành ba phần: mô hình, khung nhìn và bộ điều khiển.

Mô hình quản lý các hành vi cơ bản và dữ liệu của ứng dụng. Nó có thể đáp ứng các yêu cầu thông tin, trả lời các hướng dẫn để thay đổi trạng thái thông tin của nó và thậm chí để thông báo cho các nhà quan sát trong các hệ thống hướng sự kiện khi thông tin thay đổi. Đây có thể là cơ sở dữ liệu hoặc bất kỳ số lượng cấu trúc dữ liệu hoặc hệ thống lưu trữ nào. Nói tóm lại, đó là dữ liệu và quản lý dữ liệu của ứng dụng.

Khung nhìn cung cấp hiệu quả yếu tố giao diện người dùng của ứng dụng. Nó sẽ kết xuất dữ liệu từ mô hình thành một hình thức phù hợp với giao diện người dùng.

Bộ điều khiển nhận đầu vào của người dùng và thực hiện các cuộc gọi đến các đối tượng mô hình và khung nhìn để thực hiện các hành động thích hợp.

Nói chung, ba thành phần này phối hợp với nhau để tạo ra ba thành phần cơ bản của MVC.

Sự giống nhau

Tôi đã giải thích MVC cho bố tôi như thế này:

MVC (Model, View, Controller) là một mẫu để tổ chức mã trong một ứng dụng để cải thiện khả năng bảo trì.

Hãy tưởng tượng một nhiếp ảnh gia với máy ảnh của mình trong một studio. Một khách hàng yêu cầu anh ta chụp ảnh một chiếc hộp.

Hộp là mô hình , nhiếp ảnh gia là bộ điều khiển và máy ảnh là chế độ xem .

Bởi vì hộp không biết về máy ảnh hoặc nhiếp ảnh gia, nó hoàn toàn độc lập. Sự tách biệt này cho phép nhiếp ảnh gia đi xung quanh hộp và hướng máy ảnh vào bất kỳ góc nào để có được bức ảnh / góc nhìn mà anh ta muốn.

Các kiến ​​trúc phi MVC có xu hướng được tích hợp chặt chẽ với nhau. Nếu hộp, bộ điều khiển và máy ảnh là một đối tượng giống nhau, thì chúng ta sẽ phải tách ra và sau đó xây dựng lại cả hộp và máy ảnh mỗi lần chúng ta muốn có một chế độ xem mới. Ngoài ra, chụp ảnh sẽ luôn giống như cố chụp ảnh tự sướng - và điều đó không phải lúc nào cũng dễ dàng.

Giải thích chi tiết

Chỉ sau khi đọc câu hỏi / câu trả lời maillist sau đây, tôi cảm thấy như mình đã hiểu MVC. Trích dẫn: https://mail.python.org/pipermail/python-list/2006-Janemony/394968.html

bwaha đã viết:

Tác giả đề cập đến mvctree.py trong wxPython như một ví dụ về thiết kế MVC. Tuy nhiên tôi vẫn còn quá xanh nên tôi thấy ví dụ cụ thể đó quá phức tạp và tôi không hiểu sự tách biệt mà tác giả đang đề xuất.

MVC là tất cả về sự tách biệt của mối quan tâm.

Model chịu trách nhiệm quản lý dữ liệu của chương trình (cả dữ liệu riêng tư và dữ liệu khách hàng). Chế độ xem / Điều khiển chịu trách nhiệm cung cấp cho thế giới bên ngoài các phương tiện để tương tác với dữ liệu khách hàng của chương trình.

Mô hình cung cấp giao diện nội bộ (API) để cho phép các phần khác của chương trình tương tác với nó. Chế độ xem / Trình điều khiển cung cấp giao diện bên ngoài (GUI / CLI / biểu mẫu web / IPC cấp cao / v.v.) để cho phép mọi thứ nằm ngoài chương trình để giao tiếp với nó.

Model có trách nhiệm duy trì tính toàn vẹn của dữ liệu của chương trình, bởi vì nếu điều đó bị hỏng thì đó là trò chơi dành cho tất cả mọi người. Chế độ xem / Trình điều khiển chịu trách nhiệm duy trì tính toàn vẹn của giao diện người dùng, đảm bảo tất cả các chế độ xem văn bản đang hiển thị các giá trị cập nhật, vô hiệu hóa các mục menu không áp dụng cho tiêu điểm hiện tại, v.v.

Model không chứa mã View / Controller; không có các lớp widget GUI, không có mã để đặt hộp thoại hoặc nhận đầu vào của người dùng. Chế độ xem / Trình điều khiển không chứa mã Model; không có mã để xác thực URL hoặc thực hiện các truy vấn SQL và cũng không có trạng thái ban đầu: mọi dữ liệu được giữ bởi các widget chỉ nhằm mục đích hiển thị và chỉ đơn thuần là sự phản ánh của dữ liệu thực được lưu trữ trong Mô hình.

Bây giờ, đây là thử nghiệm của một thiết kế MVC thực sự: về bản chất chương trình phải có đầy đủ chức năng ngay cả khi không có Chế độ xem / Trình điều khiển đi kèm. OK, thế giới bên ngoài sẽ gặp khó khăn khi tương tác với nó ở dạng đó, nhưng miễn là người ta biết các câu thần chú API mô hình phù hợp, chương trình sẽ giữ và thao tác dữ liệu như bình thường.

Tại sao điều này có thể? Chà, câu trả lời đơn giản là tất cả là nhờ vào sự ghép nối thấp giữa các lớp Model và View / Controller. Tuy nhiên, đây không phải là câu chuyện đầy đủ. Chìa khóa của toàn bộ mô hình MVC là hướng mà các kết nối đó đi theo: TẤT CẢ các hướng dẫn từ Chế độ xem / Trình điều khiển đến Mô hình. Model KHÔNG BAO GIỜ cho View / Bộ điều khiển phải làm gì.

Tại sao? Bởi vì trong MVC, trong khi Chế độ xem / Trình điều khiển được phép biết một chút về Mô hình (cụ thể là API của Mô hình), nhưng Mô hình không được phép biết bất cứ điều gì về Chế độ xem / Trình điều khiển.

Tại sao? Bởi vì MVC là về việc tạo ra một sự tách biệt rõ ràng của mối quan tâm.

Tại sao? Để giúp ngăn chặn sự phức tạp của chương trình vượt khỏi tầm kiểm soát và chôn vùi bạn, nhà phát triển, theo nó. Chương trình càng lớn, số lượng thành phần trong chương trình đó càng lớn. Và càng có nhiều kết nối tồn tại giữa các thành phần đó, các nhà phát triển càng khó duy trì / mở rộng / thay thế các thành phần riêng lẻ hoặc thậm chí chỉ cần làm theo cách toàn bộ hệ thống hoạt động. Hãy tự hỏi mình điều này: khi nhìn vào sơ đồ cấu trúc của chương trình, bạn có muốn nhìn thấy một cái cây hay cái nôi của mèo không? Mẫu MVC tránh cái sau bằng cách không cho phép các kết nối vòng tròn: B có thể kết nối với A, nhưng A không thể kết nối với B. Trong trường hợp này, A là Model và B là View / Controller.

BTW, nếu bạn sắc sảo, bạn sẽ nhận thấy sự cố với hạn chế 'một chiều' vừa được mô tả: Làm thế nào Mô hình có thể thông báo cho Chế độ xem / Điều khiển các thay đổi trong dữ liệu người dùng của Mô hình khi Mô hình thậm chí không được phép biết rằng View / Controller, đừng bận tâm gửi tin nhắn đến nó? Nhưng đừng lo lắng: có một giải pháp cho vấn đề này, và nó khá gọn gàng ngay cả khi ban đầu nó có vẻ hơi vòng vo. Chúng tôi sẽ trở lại với điều đó trong một thời điểm.

Về mặt thực tế, sau đó, một đối tượng Chế độ xem / Trình điều khiển có thể, thông qua API của Mô hình, 1. yêu cầu Mô hình thực hiện (thực hiện các lệnh) và 2. yêu cầu Mô hình cung cấp cho nó mọi thứ (trả về dữ liệu). Lớp View / Controller đẩy các hướng dẫn đến lớp Model và kéo thông tin từ lớp Model.

Và đó là nơi mà ví dụ MyCoolListControl đầu tiên của bạn gặp trục trặc, bởi vì API cho lớp đó yêu cầu thông tin đó được đẩy vào đó, vì vậy bạn quay lại để có một khớp nối hai chiều giữa các lớp, vi phạm quy tắc MVC và đưa bạn trở lại vào kiến trúc cái nôi của mèo mà bạn [có lẽ] đang cố gắng tránh ở nơi đầu tiên.

Thay vào đó, lớp MyCoolListControl sẽ đi theo luồng, kéo dữ liệu cần thiết từ lớp bên dưới, khi cần. Trong trường hợp tiện ích danh sách, điều đó thường có nghĩa là hỏi có bao nhiêu giá trị và sau đó hỏi lần lượt từng mục đó, bởi vì đó là cách đơn giản nhất và lỏng lẻo nhất để thực hiện và do đó giữ cho khớp nối ở mức tối thiểu. Và nếu tiện ích muốn, giả sử, để trình bày các giá trị đó cho người dùng theo thứ tự bảng chữ cái đẹp thì đó là nhận thức của nó; và trách nhiệm của nó, tất nhiên.

Bây giờ, một câu hỏi hóc búa cuối cùng, như tôi đã gợi ý trước đó: làm thế nào để bạn giữ cho màn hình của UI được đồng bộ hóa với trạng thái của Model trong một hệ thống dựa trên MVC?

Đây là vấn đề: nhiều đối tượng Xem ở trạng thái, ví dụ: hộp kiểm có thể được đánh dấu hoặc chưa sử dụng, trường văn bản có thể chứa một số văn bản có thể chỉnh sửa. Tuy nhiên, MVC ra lệnh rằng tất cả dữ liệu người dùng được lưu trữ trong lớp Mô hình, do đó, bất kỳ dữ liệu nào được giữ bởi các lớp khác cho mục đích hiển thị (trạng thái của hộp kiểm, văn bản hiện tại của trường văn bản) phải là bản sao phụ của dữ liệu Mô hình chính đó. Nhưng nếu trạng thái của Mô hình thay đổi, bản sao trạng thái của Chế độ xem đó sẽ không còn chính xác nữa và cần được làm mới.

Nhưng bằng cách nào? Mẫu MVC ngăn Mô hình đẩy một bản sao mới của thông tin đó vào lớp View. Heck, nó thậm chí không cho phép Model gửi tin nhắn Xem thông báo trạng thái của nó đã thay đổi.

Vâng, gần như vậy. Được rồi, lớp Model không được phép nói chuyện trực tiếp với các lớp khác, vì để làm như vậy sẽ yêu cầu nó biết điều gì đó về các lớp đó và các quy tắc MVC ngăn chặn điều đó. Tuy nhiên, nếu một cái cây rơi trong rừng và không có ai xung quanh để nghe nó, liệu nó có phát ra âm thanh không?

Câu trả lời, bạn thấy, là thiết lập một hệ thống thông báo, cung cấp cho lớp Model một nơi mà nó có thể thông báo cho không ai nói riêng rằng nó vừa làm một điều gì đó thú vị. Các lớp khác sau đó có thể đăng người nghe với hệ thống thông báo đó để lắng nghe những thông báo mà họ thực sự quan tâm. Lớp Mô hình không cần biết gì về việc ai đang nghe (hoặc ngay cả khi có ai nghe cả!); nó chỉ đăng một thông báo và sau đó quên nó đi. Và nếu bất cứ ai nghe thấy thông báo đó và cảm thấy muốn làm gì đó sau đó - như hỏi Model cho một số dữ liệu mới để nó có thể cập nhật màn hình trên màn hình của nó - thì thật tuyệt. Mô hình chỉ liệt kê những thông báo mà nó gửi như một phần của định nghĩa API; và những gì người khác làm với kiến ​​thức đó là tùy thuộc vào họ.

MVC được bảo tồn, và mọi người đều hạnh phúc. Khung ứng dụng của bạn cũng có thể cung cấp một hệ thống thông báo tích hợp hoặc bạn có thể tự viết nếu không (xem 'mẫu quan sát viên').

...

Dù sao, hy vọng rằng sẽ giúp. Khi bạn hiểu được các động lực đằng sau MVC, lý do tại sao mọi thứ được thực hiện theo cách chúng bắt đầu có ý nghĩa, ngay cả khi - thoạt nhìn - chúng có vẻ phức tạp hơn mức cần thiết.

Chúc mừng

có

MVC chủ yếu là một từ thông dụng.

Nó từng được coi là một mô hình, nhưng định nghĩa ban đầu năm 1979 của nó đã bị làm cho ngớ ngẩn, bị bỏ qua, bị giải thích sai, được đưa ra khỏi bối cảnh ban đầu. Nó đã được định nghĩa lại đến mức nó bắt đầu giống với một tôn giáo, và trong khi điều này chắc chắn giúp những người sùng bái hàng hóa của nó bảo vệ nó, tên của nó không còn liên kết với một bộ hướng dẫn vững chắc . Như vậy, nó thực sự không thể được coi là một mô hình nữa.

MVC không bao giờ có nghĩa là để mô tả các ứng dụng web.
Không phải hệ điều hành hiện đại, cũng không phải ngôn ngữ.
(một số người thực sự đã làm cho định nghĩa năm 1979 trở nên dư thừa)

Nó đã được thực hiện để. Và nó đã không thành công.

Bây giờ chúng ta đối phó với một web-mvc lai tục tĩu , với trạng thái từ thông dụng khủng khiếp, định nghĩa xấu và có các lập trình viên bán mù chữ như một nhân khẩu học mục tiêu, nói chung công khai thực sự xấu đối với các mẫu phần mềm.

Do đó, MVC trở thành sự tách biệt các mối quan tâm đối với những người không thực sự muốn nghĩ quá nhiều về nó.

• Các dữ liệu mô hình được xử lý một cách,
• các quan điểm trong một,
• phần còn lại chỉ được đặt tên là "bộ điều khiển" và tùy ý người đọc.

Các trang web / ứng dụng web trong thập niên 90 không thực sự sử dụng để áp dụng các mối quan tâm.

Chúng là những con bot khủng khiếp của mã spaghetti xen kẽ.
Thay đổi giao diện người dùng, thiết kế lại và sắp xếp lại dữ liệu là vô cùng khó khăn, tốn kém, lâu dài, chán nản, tồi tệ.

Các công nghệ web như ASP, JSP và PHP làm cho quá dễ dàng để xen kẽ các mối quan tâm với dữ liệu và các mối quan tâm về ứng dụng. Những người mới đến với lĩnh vực này thường phát ra những quả bóng bùn mã không thể mã hóa như trong thời đại cũ.

Do đó, ngày càng nhiều người bắt đầu lặp lại "sử dụng MVC" trong các vòng lặp vô tận trên các diễn đàn hỗ trợ. Số lượng người mở rộng đến mức bao gồm cả các nhà quản lý và tiếp thị, (với một số thuật ngữ đã quen thuộc, từ thời đó trong lập trình gui, trong đó mô hình có ý nghĩa) và điều đó đã trở thành thói quen của một từ thông dụng mà chúng ta phải đối mặt bây giờ .

Vì nó là ý nghĩa thông thường , không phải là một phương pháp .
Đó là một điểm khởi đầu , không phải là một giải pháp .
Nó giống như bảo mọi người hít thở không khí, hoặc tạo ra những cơn đau , không phải là thuốc chữa ung thư .

Cách tốt nhất để xác định nó là đi đến các tác phẩm gốc của Trygve Reenskaug , người đã phát minh ra nó: http://heim.ifi.uio.no/~trygver/theme/mvc/mvc-index.html

Đặc biệt, bài viết này thường được coi là văn bản xác định: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MÔ HÌNH

Mô hình đại diện cho kiến ​​thức. Một mô hình có thể là một đối tượng duy nhất (khá không thú vị) hoặc nó có thể là một số cấu trúc của các đối tượng ...

Cần có một sự tương ứng một-một giữa mô hình và các bộ phận của nó một mặt và thế giới đại diện theo cảm nhận của chủ sở hữu mô hình. Do đó, các nút của một mô hình nên đại diện cho một phần xác định của vấn đề.

Tất cả các nút của một mô hình phải ở cùng một mức độ vấn đề, nó gây nhầm lẫn và được coi là hình thức xấu để trộn các nút định hướng vấn đề (ví dụ như các cuộc hẹn lịch) với các chi tiết triển khai (ví dụ đoạn văn).

LƯỢT XEM

Một khung nhìn là một đại diện (trực quan) của mô hình của nó. Nó thường làm nổi bật các thuộc tính nhất định của mô hình và triệt tiêu các thuộc tính khác. Do đó, nó hoạt động như một bộ lọc trình bày .

Một khung nhìn được gắn vào mô hình của nó (hoặc một phần mô hình) và lấy dữ liệu cần thiết cho bài thuyết trình từ mô hình bằng cách đặt câu hỏi. Nó cũng có thể cập nhật mô hình bằng cách gửi tin nhắn thích hợp. Tất cả những câu hỏi và thông điệp này phải nằm trong thuật ngữ của mô hình, do đó, khung nhìn sẽ phải biết ngữ nghĩa của các thuộc tính của mô hình mà nó đại diện. (Ví dụ, nó có thể yêu cầu định danh của mô hình và mong đợi một thể hiện của Văn bản, nó có thể không cho rằng mô hình đó là Văn bản lớp.)

KIỂM SOÁT

Bộ điều khiển là liên kết giữa người dùng và hệ thống. Nó cung cấp cho người dùng đầu vào bằng cách sắp xếp các chế độ xem phù hợp để hiển thị ở những vị trí thích hợp trên màn hình. Nó cung cấp phương tiện cho đầu ra của người dùng bằng cách hiển thị cho người dùng các menu hoặc các phương tiện khác để đưa ra lệnh và dữ liệu. Bộ điều khiển nhận đầu ra của người dùng như vậy, chuyển nó thành các thông báo phù hợp và chuyển các thông báo này vào .to một hoặc nhiều lượt xem.

Một bộ điều khiển không bao giờ nên bổ sung các khung nhìn, ví dụ, nó sẽ không bao giờ kết nối các khung nhìn của các nút bằng cách vẽ các mũi tên giữa chúng.

Ngược lại, một chế độ xem không bao giờ nên biết về đầu vào của người dùng, chẳng hạn như thao tác chuột và tổ hợp phím. Luôn luôn có thể viết một phương thức trong bộ điều khiển gửi tin nhắn đến các khung nhìn để tái tạo chính xác bất kỳ chuỗi lệnh người dùng nào.

CHỈNH SỬA

Một bộ điều khiển được kết nối với tất cả các khung nhìn của nó, chúng được gọi là các bộ phận của bộ điều khiển. Một số khung nhìn cung cấp một bộ điều khiển đặc biệt, một trình soạn thảo , cho phép người dùng sửa đổi thông tin được trình bày bởi khung nhìn. Các trình soạn thảo như vậy có thể được ghép vào đường dẫn giữa bộ điều khiển và khung nhìn của nó, và sẽ hoạt động như một phần mở rộng của bộ điều khiển. Khi quá trình chỉnh sửa hoàn tất, trình chỉnh sửa sẽ bị xóa khỏi đường dẫn và bị loại bỏ.

Lưu ý rằng một trình soạn thảo giao tiếp với người dùng thông qua các ẩn dụ của chế độ xem được kết nối, do đó trình chỉnh sửa được liên kết chặt chẽ với chế độ xem. Một bộ điều khiển sẽ nắm giữ một trình soạn thảo bằng cách hỏi khung nhìn cho nó - không có nguồn thích hợp nào khác.

MVC là một mẫu thiết kế được sử dụng để tách biệt logic kinh doanh khỏi cách trình bày.

Nó khác với rất nhiều mẫu thiết kế khác bởi thực tế là nó thường không được triển khai ngắn gọn, nhưng là cơ sở của một khung.

Mặc dù một ứng dụng triển khai mẫu Chiến lược chỉ là một chi tiết nhỏ về nó, nhưng nói rằng một ứng dụng web sử dụng mẫu thiết kế MVC rất rõ ràng về kiến ​​trúc của nó .

MVC là một thiết kế phần mềm phân tách các thành phần sau của hệ thống hoặc hệ thống con:

1. Mô hình - Dữ liệu về trạng thái của ứng dụng hoặc các thành phần của ứng dụng. Có thể bao gồm các thói quen để sửa đổi hoặc truy cập.
2. Xem - Giải thích dữ liệu (mô hình). Điều này chỉ giới hạn ở một biểu diễn trực quan, nhưng có thể là âm thanh, thông tin dẫn xuất (ví dụ: thống kê được dẫn vào một đối tượng mô hình khác), v.v. Hơn nữa, một mô hình duy nhất có thể có nhiều chế độ xem.
3. Điều khiển - Xử lý đầu vào bên ngoài cho hệ thống yêu cầu sửa đổi trên mô hình. Điều khiển / khung nhìn có thể liên quan chặt chẽ (trong trường hợp UI). Tuy nhiên, đầu vào bên ngoài khác (như lệnh mạng), có thể được xử lý hoàn toàn độc lập với chế độ xem.

Tôi muốn nói rằng MVC là một khái niệm hoặc một họ các mẫu tương tự.

Tôi nghĩ rằng bài viết này là đáng để đọc. Kiến trúc GUI của Martin Fowler

Đầu tiên, bạn phải xác định ai là người hỏi của câu hỏi và loại câu trả lời mà anh ta đang tìm kiếm. Bạn trả lời câu hỏi này bằng một câu hỏi khác, chẳng hạn như "Theo nghĩa nào?"

Bạn có thể hỏi xem họ có nói đến MVC nói chung không, một triển khai cụ thể của MVC (ví dụ: asp.net MVC, spring MVC, smalltalk MVC, v.v.), về mặt kỹ thuật, nó là gì về mặt triết học (vâng, nó có triết học là tốt), vv ..

Nếu đây là một câu hỏi trong bài kiểm tra và bạn không thể yêu cầu người hỏi làm rõ, thì bạn sẽ phải đoán dựa trên ngữ cảnh.

Một câu trả lời hay, đơn giản là:

MVC là một kiến ​​trúc giao diện người dùng phần mềm được sử dụng để ngăn cách các mối quan tâm về cấu trúc và hành vi nhằm tạo điều kiện cho các phần mềm dễ bảo trì hơn.

Bạn cũng có thể nói:

Bằng cách tách biệt Chế độ xem từ Bộ điều khiển khỏi Mô hình, nó khuyến khích cách ly các thành phần dựa trên trách nhiệm của chúng. Về lý thuyết, và thường là trong thực tế, điều này giúp cải thiện khả năng bảo trì bằng cách ngăn chặn các phần khác nhau của hệ thống kết hợp và tạo ra các hệ thống phức tạp hơn.

Nhưng, cuối cùng, bạn sẽ được đánh giá xem bạn có đưa ra câu trả lời mà họ đang mong đợi hay không. Giải pháp duy nhất cho vấn đề là tìm ra loại câu trả lời mà họ đang mong đợi.

Đây là những gì tôi sẽ nói về nó. Tôi sẽ cố gắng giải thích nó về các ứng dụng di động, bởi vì đó là những gì tôi quen thuộc nhất và vì tôi không nghĩ rằng tôi hoàn toàn hiểu nó trước khi bắt đầu làm các ứng dụng di động.
Hãy lấy Android làm ví dụ.
Lớp trình bày, tức là. giao diện người dùng có thể (nên, thường xuyên nhất là) được chỉ định hoàn toàn trong xml. Để đơn giản, giả sử rằng một tệp xml mô tả một màn hình trong ứng dụng. Tệp XML chỉ định các điều khiển, bố cục của các điều khiển, định vị, màu sắc, kích thước, nhãn chuỗi ... mọi thứ liên quan đến việc trình bày. Tuy nhiên, nó không biết gì khi nào nó sẽ được gọi, khi nào nó sẽ được đặt trên màn hình. Nó sẽ là một bố cục độc lập hay là một phần của một số bố cục lớn hơn? Ở đó bạn có nó: XEM hoàn hảo của bạn .

Bây giờ, xem rõ ràng cần phải được đặt trên màn hình tại một số điểm, vậy làm thế nào để làm điều đó? ĐIỀU KHIỂN của bạn , trong Android được gọi là Hoạt động. Như tên đã nói, hoạt động làm một số hoạt động. Ngay cả khi mục đích duy nhất của nó là hiển thị chế độ xem được xác định trong bước 1, nó sẽ thực hiện một số hành động. Vì vậy, hoạt động tìm nạp một chế độ xem và hiển thị nó trên màn hình. Vì chế độ xem không biết gì về hoạt động, hoạt động tương tự không biết gì về cách trình bày thực tế. Chúng tôi (các lập trình viên) có thể sắp xếp lại bố cục của khung nhìn nhiều lần, mà không thay đổi ngay cả một dòng mã trong hoạt động của chúng tôi.

Bây giờ, không có nhiều sử dụng trong việc trình bày bố cục xml sáng bóng, đẹp mắt của bạn mà không thực sự làm gì đó. Giả sử chúng tôi muốn lưu trữ dữ liệu được nhập bởi người dùng. Hoạt động cần giải quyết quá trình này từ việc lấy dữ liệu từ người dùng để chuyển nó cho người khác để xử lý nó (xử lý, lưu trữ, xóa nó). Nó sẽ vượt qua ai? Vâng, với một MÔ HÌNH . Tôi thích nghĩ về một mô hình như một thuần túy. lớp java không biết gì về bối cảnh ứng dụng mà nó sống. (Trong thực tế điều đó sẽ gần như không bao giờ xảy ra).

Giả sử tôi có một lớp Người có ba thuộc tính: tên, địa chỉ, tuổi. Bố cục được xác định XML của tôi có 3 trường cho đầu vào của người dùng: tên, địa chỉ, tuổi. Hoạt động của tôi lấy ba giá trị từ đầu vào của người dùng, tạo một đối tượng Person mới và gọi một số phương thức trên đó để biết cách xử lý một số logic cụ thể của Người. Có bạn có nó. Bộ điều khiển xem mô hình.

Tôi luôn bắt đầu bằng cách nói với họ rằng mô hình đó không phải là bất cứ điều gì mới và đã tồn tại trong nhiều năm ... đến thời điểm này, họ cho tôi một cái nhìn tò mò và BAM!, Họ bị cuốn hút:

Và sau đó tôi sẽ nói khá nhiều về các điểm khác nhau như các câu trả lời trước đó, nhưng tôi nghĩ nó cũng quan trọng theo ngữ cảnh, như JB King đã nói, ASP.NET MVC, v.v.