Tôi có nhu cầu giải thích MVC cho những người không lập trình. Cụ thể, để quản lý của các bộ phận khác, trong bối cảnh báo cáo tiến độ. Một trong những điều tôi làm là cấu trúc lại cơ sở mã của chúng tôi theo hướng tách MVC.

Phân tách MVC họ có thể yêu cầu là gì? Tại sao cần thiết họ có thể hỏi?

Sau khi đọc một câu trả lời khá kỹ thuật như thế này: MVC thực sự là gì? , Tôi không hoàn toàn hài lòng, vì tôi sẽ nói chuyện với những người không lập trình. Họ có thể gật đầu nhưng có lẽ họ sẽ không hiểu nó là gì và tại sao nó lại cần thiết.

Trong thực tế, tôi không hoàn toàn nắm bắt được MVC là gì ngoài "phân tách mối quan tâm, nhiệm vụ, chức năng, lớp, khối, nhiệm vụ, mọi thứ, để cải thiện tính linh hoạt của việc thay đổi phần mềm". Tách cơ sở dữ liệu khỏi chế độ xem và chế độ xem khỏi logic nghiệp vụ bằng các kỹ thuật như các công cụ và kỹ thuật DI và OO là điều tôi coi là tách MVC.

Vì vậy, lần tới khi bạn đang giải thích MVC cho một người không phải là lập trình viên có nền tảng về bán hàng và kế toán chẳng hạn, bạn sẽ nói gì với họ?

Bạn không giải thích MVC.

Những gì bạn làm là giải thích rằng đây là sự tái cấu trúc của cơ sở mã.

Việc tái cấu trúc giúp đơn giản hóa cơ sở mã và do đó cho phép các nhà phát triển thực hiện các thay đổi nhanh hơn và tốt hơn cho các báo cáo lỗi và yêu cầu tính năng, với ít lỗi hơn.

Họ không cần biết các chi tiết kỹ thuật, tại sao nó được thực hiện, những gì đạt được bằng cách thực hiện và lợi ích kinh doanh như thế nào.

Nói cách khác - nói ngôn ngữ của họ với họ.

Trong khi tôi tán thành ý chính của của câu trả lời của Oded , rằng bạn nên giải thích các dự án kỹ thuật cho các nhà quản lý doanh nghiệp bằng "ngôn ngữ của họ", tôi có một câu hỏi về "họ không cần biết chi tiết kỹ thuật, tại sao nó lại được thực hiện."

Nếu bạn đang trong một cuộc họp đánh giá dự án hoặc đầu tư với các trưởng bộ phận và bạn tuyên bố "đây là những gì chúng tôi đang làm", họ có thể muốn hỏi "Umm ... tại sao? Đó có vẻ như là một khoản đầu tư lớn về thời gian và năng lượng. Bạn có thể cho chúng tôi hiểu thêm một chút về những gì bạn đang làm và tại sao không? " Đó có vẻ là một câu hỏi hợp lý. Bạn không muốn bị bắt gặp ở vị trí "Chà ... thật phức tạp." hoặc "Không, tôi thực sự không thể giải thích nó." hoặc "Đừng lo lắng về điều đó." Các nhân viên càng cao cấp mà bạn đang thực hiện đánh giá dự án, họ càng ít có khả năng để "đó chỉ là thứ tôi không thể giải thích tốt". Tốt hơn nếu bạn có thể đi sâu ít nhất một cấp để khiến người khác cảm thấy thoải mái rằng 1) bạn biết bạn là gì

Vì vậy, có một bản phác thảo của MVC trong túi hông của bạn, sẵn sàng để đi. Cái gì đó như:

"Đó là một chút kỹ thuật, nhưng ... MVC chia mã thành các Mô hình (chịu trách nhiệm về dữ liệu cốt lõi và logic nghiệp vụ), Khung nhìn (hiển thị dữ liệu) và Bộ điều khiển (xử lý các tương tác và cập nhật của người dùng). "mô hình thiết kế" thành công nhất của kỹ thuật phần mềm. Tôi biết nó có vẻ giống như "chỉ là một hệ thống ống nước", nhưng để xử lý tất cả các yêu cầu đến, chúng ta cần một nền tảng vững chắc hơn. tính năng và giải quyết lỗi nhanh hơn. "

Ngay cả khi họ không hiểu đầy đủ về MVC ở phần cuối của nó và ngay cả khi bạn phải đơn giản hóa quá mức để làm cho nó dễ hiểu ("phá vỡ một số trứng để làm món trứng tráng"), tôi cá rằng bạn sẽ thấy thoải mái hơn nhiều có một lời giải thích sẵn sàng hơn là phải nói "Tôi không thể giải thích nó" hoặc "bạn không đủ điều kiện để hiểu nó" với các nhà quản lý cấp cao.

để cải thiện tính linh hoạt của việc thay đổi phần mềm

Các nhà quản lý quan tâm đến kết quả cuối cùng. Họ càng ít kỹ thuật thì họ càng ít quan tâm đến cách bạn đến đó. MVC là rất phổ biến, phổ biến và đã được chứng minh.

Khi các yêu cầu thay đổi được thực hiện trong tương lai, bạn có thể cho quản lý biết rằng chúng có thể được thực hiện dễ dàng và nhanh hơn. Mọi người đều thích nghe điều này.

Đây là một chiến lược phổ biến, vì vậy việc thuê các nhà phát triển mới không nên đưa ra một vấn đề. Trên thực tế, bạn có thể thu hút các nhà phát triển tốt hơn, những người đề xướng mạnh mẽ.

Đây là tất cả sẽ rất khó khăn nếu có nhiều vấn đề cấp bách trong dự án cụ thể này. Họ có thể không sẵn sàng lùi lại một bước để bạn có thể tiến lên hai bước. Trên giải pháp có thể là chờ đợi hoặc thực hiện trong phần nhỏ hơn.

• Model - Dây điện / điện
• Xem - Lịch thi đấu
• Bộ điều khiển - Công tắc đèn

Tương đối dễ dàng để tắt các thành phần (vật cố ánh sáng, công tắc đèn / bộ điều chỉnh độ sáng). Có thể không quá nhiều dây, nhưng vẫn có thể được thực hiện mà không ảnh hưởng đến các thành phần khác. Mọi người nên có thể hình dung rằng trong đầu của họ, thậm chí các loại tiếp thị / bán hàng. (Xóa tách, v.v.)

Bây giờ hãy nói với sếp / đồng nghiệp của bạn rằng trong ứng dụng / hệ thống của chúng tôi, công tắc được nhúng bên trong vật cố ánh sáng và vật cố ánh sáng được quấn quanh bằng dây đồng. Bây giờ hãy tưởng tượng thử cập nhật các vật cố ánh sáng, công tắc hoặc dây. Rất tốn kém, tác động đến các thành phần khác rất cao và có thể nguy hiểm để làm mà không phá vỡ một cái gì đó khác.

MVC đang áp dụng một mô hình cho cơ sở mã để biến mớ hỗn độn (nhưng đang hoạt động) thành một thứ mà sự thay đổi có thể xảy ra nhanh hơn và dễ dàng hơn với ít lỗi hơn.

Một cách dễ dàng để hiểu MVC: các mô hình là các dữ liệu , các quan điểm là cửa sổ trên màn hình , và các bộ điều khiển là keo giữa hai .

Phiếu tự đánh giá tốt nhất từng có: "Chúng tôi cần Mô hình SMART, Bộ điều khiển THIN và Chế độ xem DUMB"

Cũng như các mẫu thiết kế phần mềm khác, MVC thể hiện " cốt lõi của giải pháp " cho một vấn đề trong khi cho phép nó được điều chỉnh cho từng hệ thống. Nó được xem tốt hơn như là một khái niệm thay vì thực hiện cụ thể. Có nhiều triển khai của khái niệm này.

Tất cả các biến thể MVC sử dụng cùng một phân chia các thành phần, nhưng thông thường chúng khác nhau về cách các thành phần đó tương tác.

Đối với những người bạn không biết, MVC ban đầu được mô tả theo mô hình thiết kế để sử dụng với Smalltalk bởi Trygve Reenskaug vào năm 1979 . Bài viết của ông đã được xuất bản với tiêu đề "Lập trình ứng dụng trong Smalltalk-80: Cách sử dụng Model-View-Controller" và mở đường nền tảng cho hầu hết các triển khai MVC trong tương lai.

Tôi đồng ý với Oded - học cách thuyết phục các đồng nghiệp và quản lý phi kỹ thuật của bạn rằng những gì bạn đang làm là quan trọng và hữu ích, mà không giải thích các chi tiết nghiệt ngã, là một kỹ năng cần thiết mà bạn sẽ khôn ngoan phát triển.

Tuy nhiên, tôi tin rằng việc có khả năng giải thích các khái niệm phức tạp bằng các thuật ngữ đơn giản thực sự giúp ích cho điều đó - một vấn đề mà các nhà quản lý phi kỹ thuật thường gặp là vì họ gặp khó khăn trong việc hiểu chính xác những gì dân công nghệ đang làm, họ có xu hướng không tin tưởng họ Đó chỉ là bản chất của con người: dễ dàng tin rằng một điều gì đó bạn không hiểu là vô ích hoặc sai lầm hơn là đặt niềm tin của bạn vào đó. Do đó, nếu bạn có thể làm cho các khái niệm dễ hiểu theo ý muốn, bạn có thể sử dụng nó bất cứ khi nào bạn cần và theo thời gian, các nhà quản lý phi kỹ thuật của bạn sẽ biết rằng họ có thể hiểu nó nếu họ muốn - bạn không kéo theo về họ - bạn chỉ tiết lộ cho họ các chi tiết cho sự tỉnh táo của riêng họ. Họ sẽ tin tưởng bạn hơn.

Bỏ qua chuyện đó, hãy trả lời câu hỏi:

Tôi thấy nó hữu ích để sử dụng các chất tương tự mà những người kinh doanh hiểu. Đối với MVC, tôi mô tả nó như là một doanh nghiệp.

• Các mô hình chịu trách nhiệm về logic và dữ liệu kinh doanh - chúng là những thứ xác định những gì chương trình làm và chi tiết về cách thức thực hiện. Nếu chương trình là một doanh nghiệp, thì các mô hình sẽ là nhà kho, nhà máy, công nhân và thiết bị vốn. Họ cũng sẽ là người quản lý cấp thấp hơn đảm bảo các quy tắc được tuân thủ và chính sách được thi hành.
• Lượt xem là lớp trình bày - chúng hiển thị cho người dùng những gì đang diễn ra trong hệ thống và cung cấp phương tiện để tương tác với chương trình. Nếu chương trình của chúng tôi là một công ty, các lượt xem sẽ giống như sàn showroom, gian hàng bán hàng tại hội nghị thương mại hoặc đại diện bán hàng. Họ hiển thị các tùy chọn, cung cấp thông tin và phản hồi thân thiện với người dùng và nhận yêu cầu quay lại công ty.
• Bộ điều khiển là lớp phối hợp - họ đảm bảo rằng thông tin nhận được từ các mô hình đến các khung nhìn và ngược lại, và mọi thứ hoạt động cùng nhau để thực hiện công việc của họ. Nếu chương trình là một công ty, thì bộ điều khiển sẽ là quản lý cấp trung và cấp cao. Họ không tham gia vào các chi tiết, nhưng họ đảm bảo rằng đúng người có công cụ phù hợp để thực hiện công việc của họ và họ chấp thuận hoặc từ chối các quyết định cấp cao. Họ cung cấp định hướng tổng thể để mọi thứ có thể làm việc cùng nhau.

Lợi ích của việc giải thích nó với sự tương tự này là một người quản lý giỏi sẽ nhìn thấy sự khôn ngoan trong việc tách biệt mối quan tâm theo cách này và có thể quyết định rằng họ nên giống người điều khiển hơn và không tham gia vào các chi tiết trong tương lai!

Điều đó hy vọng sẽ trả lời "cái gì" - "tại sao" cũng dễ dàng với sự tương tự này:

Hãy tưởng tượng một công ty lý tưởng, nơi mỗi bộ phận chịu trách nhiệm cho một nhóm nhiệm vụ và biết rằng nó sẽ luôn có đủ nguồn lực cần thiết mà không phải lo lắng về những gì người khác đang làm. Một đại diện bán hàng tìm thấy một khách hàng, nhận đơn đặt hàng của họ, chuyển lại cho quản lý phê duyệt và sau đó nó đến kho / sản xuất / kỹ thuật để thực hiện. Phản hồi là trực tiếp - không ai khác cần tham gia trừ khi có vấn đề. Đó là một thiết kế MVC tốt - mỗi phần có một công việc và nó không phải lo lắng về các phần khác. Bằng cách đó, thật dễ dàng để thay đổi nếu chúng ta cần. Trong một thiết kế không phải là MVC, trách nhiệm không rõ ràng. Đại diện bán hàng có thể cố gắng sửa đổi sản phẩm khi khách hàng yêu cầu một cái gì đó khác biệt. Hoặc họ có thể đưa ra mức giá khác nhau tùy thuộc vào cảm giác của họ ngày hôm đó. Giám đốc điều hành có thể xuống sàn nhà máy gây rối với dây chuyền sản xuất, khi anh ta nên lo lắng về việc làm thế nào để có được chuỗi cung ứng đáng tin cậy hơn. Các nhân viên kho có thể ra khỏi sàn bán hàng nói chuyện với khách hàng khi họ cần hoàn thành các đơn hàng đã được thực hiện.

Nói cách khác, thiết kế MVC tốt cho phép mỗi phần tập trung vào một thứ, để nó có thể làm đúng - giống như một công ty được tổ chức tốt.

** Tuyên bố miễn trừ trách nhiệm - nếu công ty của bạn được tổ chức kém, họ có thể bị xúc phạm bởi điều này. Trong trường hợp đó, bạn sẽ cần một sự tương tự khác. Bạn cũng có thể cần một công việc khác.

Lợi ích của MVC chủ yếu là phân tách các mối quan tâm:

Nó cho phép mọi người tập trung vào những gì họ làm tốt nhất.

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

Nó giảm chi phí vì các hệ thống đan xen đòi hỏi nhân viên phải là chuyên gia trong tất cả các lĩnh vực này, hoặc bạn có nhiều khả năng gặp vấn đề khi thay đổi trên một lĩnh vực ảnh hưởng đến các khu vực khác.

Cung cấp các ví dụ thực tế về kiến ​​trúc MVC: Điện thoại di động, Điện thoại để bàn, Skype, v.v. Thay đổi Chế độ xem (loại bàn phím quay số, loa, micrô) không ảnh hưởng đến mô hình (tín hiệu âm thanh), bộ điều khiển là mạch trong điện thoại chuyển sóng âm thanh thành tín hiệu âm thanh.

Tôi sẽ nói với họ rằng MVC tách biệt mối quan tâm của tôi.

Mối quan tâm đầu tiên của tôi là logic mã - những gì tôi làm đằng sau hậu trường để làm cho trang web thực hiện các hành động mà họ muốn.

Mối quan tâm thứ hai của tôi là logic kinh doanh - những gì họ (người dùng) muốn ứng dụng làm.

Mối quan tâm thứ ba của tôi là trang web trông như thế nào - Trang họ truy cập để làm những gì họ muốn.

(Tôi sẽ không nói với họ phần tiếp theo này) Vì vậy, theo thứ tự, những lời giải thích của tôi là dành cho Mô hình, Bộ điều khiển và Chế độ xem.

Giải thích những lợi thế

Tôi sẽ giải thích MVC về lợi ích kinh doanh. Người quản lý của bạn sẽ có thể hiểu điều này, và sẽ tham gia nếu những lợi thế có sức thuyết phục.

MVC cho phép bạn chia ứng dụng của mình thành các đơn vị hợp lý, mỗi đơn vị tồn tại độc lập với các đơn vị khác. Bạn nhận được mã sạch, có thể bảo trì, có thể kiểm tra và có khả năng tái sử dụng mã giữa các hệ thống.

Ngươi mâu

Mỗi mô hình gói gọn một loại thông tin doanh nghiệp, ví dụ: hồ sơ khách hàng hoặc sản phẩm, cùng với tất cả logic kinh doanh liên quan.

Tách điều này ra cho phép bạn dễ dàng kiểm tra logic kinh doanh của mình một cách tách biệt với các phần khác trong ứng dụng của bạn.

Bạn cũng có thể dễ dàng mở rộng ứng dụng bằng cách thêm các mô hình bổ sung, nó rất mô-đun và sạch sẽ.

Mỗi mô hình trong lý thuyết có thể tồn tại độc lập với những người khác. Bạn có thể xem xét thực thi điều này bằng cách sử dụng các đối tượng dịch vụ để xử lý các mối quan hệ giữa các mô hình. Bạn có thể trao đổi các mô hình mà không ảnh hưởng đến phần còn lại của hệ thống.

Cái nhìn

Tách biệt chế độ xem của bạn cho phép bạn dễ dàng cập nhật giao diện người dùng của mình mà không phá vỡ giao diện phía sau bên dưới.

Bạn có thể cung cấp mã giao diện người dùng của mình cho nhà phát triển khác mà không nhất thiết phải cấp cho họ quyền truy cập vào toàn bộ hệ thống.

Bạn cũng có thể tự do tạo giao diện người dùng thay thế hoạt động với hệ thống hiện có. Bạn có thể hiển thị dữ liệu của mình dưới dạng ứng dụng dành cho thiết bị di động hoặc API hoặc PDF hoặc bảng tính Excel. Bạn có thể làm điều này mà không hack vào phần còn lại của hệ thống. Bạn ít có khả năng phá vỡ mọi thứ một cách tình cờ. Bạn có thể dễ dàng tạo các điểm tích hợp cho các hệ thống hiện có để kết nối.

Bộ điều khiển

Bộ điều khiển nối các mô hình để xem. Nó giữ mọi thứ riêng biệt. Bạn có thể đi dây ở một góc nhìn khác rất dễ dàng. Nếu bạn thay đổi mã mô hình của mình, chế độ xem thậm chí không cần biết.

Ưu điểm khác

Đó là một mô hình phổ biến. Các nhà phát triển khác sẽ có thể hiểu mã của bạn và làm việc với nó. Nếu bạn quay lại mã của mình nhiều năm sau, bạn có thể sẽ hiểu nó và thực hiện các thay đổi. Mã của bạn sẽ ít có khả năng trở thành một vấn đề đau đầu khác cho một nhà phát triển trong tương lai.

Bởi vì mọi thứ đều có một vị trí, việc tạo mã sạch sẽ dễ dàng hơn nhiều. Nguy cơ spaghettization giảm đáng kể (mặc dù không được loại bỏ). Mã của bạn trở nên duy trì.

Bởi vì tất cả mọi thứ là mô-đun, bạn có thể kiểm tra các phần của nó trong sự cô lập. Mã của bạn có thể kiểm tra được và ít có khả năng chứa lỗi hoặc lỗ hổng bảo mật. Nâng cấp trong tương lai sẽ dễ dàng hơn nhiều vì bạn sẽ có thể dễ dàng kiểm tra toàn bộ hệ thống.