4.
kalyaka
1079
08.04.24 08:22
Сейчас в теме
() Мне, как профессиональному разработчику, понятна тема. Но вновь прочитывая статью, чтобы вспомнить контекст, я понимаю, что тема то на самом деле сложная.
Теперь по вопросу. Потенциально эта технология дает возможность меньшими затратами получать функциональный интерфейс. Причем этот интерфейс одновременно работает и с пользователем и с другими системами (сервисами, обработками). Т.е. буквально в ситуациях, когда пользователь ввел значение скидки и произошел пересчет цены, и некий сервис (обработка) передал значение скидки в документ, а документ точно также пересчитал цены - используются одни и теже механизмы.
В "традиционном программировании" для такого поведения требуется прописать обработчики формы ПриИзменении, решить вопрос с контекстом выполнения Клиент или Сервер, вызвать алгоритм пересчета цены. Для работы сервиса также нужно знать какую процедуру пересчета нужно вызвать у документа. Т.е. разница в подходе: при MVC - подход не зависит от того, кто работает с объектом и есть ли у него интерфейс (возможно и не один), а традиционно - требуется знать внетреннее устройство объекта и подходы будут различаться для различных режимов работы. Ну и конечно количество кода при MVC будет меньше и точки изменения будут одинаковыяе для разных режимов работы.
Тут конечно можно возразить, что и при "традиционном" подходе можно вынести все процедуры обработчиков в общий модуль и вызвать их из разных режимов. Но даже в этом случае вам придется писать больше кода, т.к. потребуется некоторая "объвязка" для поддержки разных режимов вызова (интерактивный / система-система). Когда при использовании MVC все эти "объвязки" уже вынесены в отдельный фреймворк и разработчику требуется только встроиться в него.