дизайн — Ответственность за расположение элементов — фронтенд или бэкэнд?

Ответственность за расположение элементов — фронтенд или бэкэнд?

Вы и ваш коллега оба по существу правильны с точки зрения «того, что вы думаете». То, что вы пропустили, — это третий ключевой компонент современного программирования, Модель. В архитектуре Model-View-Controller (MVC) Модель представляет собой серию файлов данных, таблиц базы данных или других неких «данных», которые описывают поля, их расположение, порядок значений выбора и т. Д. ,

Представление — это то, что вы назвали «внешним интерфейсом», и действительно, оно должно содержать минимальное количество логики, как утверждает ваш коллега. Фактически, первоначально соединения с мэйнфреймом происходили через «тупой терминал». Их называли так, потому что у них практически не было логики, и они просто показывали то, что сервер отображал без изменений. Однако здесь могут быть сделаны исключения; возможно, один вид может иметь опцию «по умолчанию» вверху списка или что-то еще, но это должно быть для каждого конкретного случая.

Контроллер — это то, что вы назвали «бэкэндом», и он должен отвечать за проверку обязательных полей, соблюдение бизнес-правил и т. Д. Он также не должен конкретно определять порядок значений выбора. Он должен обратиться к модели и вернуть все, что определяет модель. В этом случае ваш контроллер неверен, возвращая модель в «обратном» порядке.

Добавляя третий компонент, вы позволяете системным администраторам изменять значения выбора, не влияя на бизнес-правила и не обновляя логику интерфейса. На самом деле, SA даже не должен быть программистом в этой ситуации, так как файлы, которые необходимо изменить, как правило, предоставляются через приложение Admin некоторой формы. Даже если вы не думаете, что вам нужна такая гибкость сейчас, обычно требуется минимальное количество усилий для того, чтобы что-то кодировать сейчас, поэтому у вас есть возможность позже.

В конечном счете, ваша система выиграет от разработки модели, которую могут использовать как интерфейсный, так и серверный компоненты для обеспечения согласованного взаимодействия. Ни сторонние, ни внутренние разработчики не должны спорить о порядке выбора значений, потому что это должен быть файл данных, который может потенциально изменяться, чтобы влиять на поведение системы без изменения кода. Конечно, теперь вам будет больше работы, но в конце концов, все будут более продуктивными с эффективной моделью на месте.


Источник: почти 15-летний опыт работы (по состоянию на 2019 г.) с salesforce.com в качестве технической поддержки, консультанта, администратора и разработчика.

Понравилась статья? Поделиться с друзьями:
JavaScript & TypeScript
Adblock
detector