Согласен, но как часто процесс разработки проходит по идеальному пути?
Ну разделить представление и логику обычно можно, если заранее на это закладываться. Потому что, как я уже писал ранее, представление зависит только от формата данных, а это уже не архитектурное решение. От дизайна может зависеть более низкоуровневая реализация (к кому обратиться за данными, в каком формате вернуть, сколько записей и т.д.), но никак не архитектура.
В таком случае дизайн это очень и очень широкое понятие
Понятие не то, что бы широкое, скорее нет чёткого однозначного определения, немного путается с архитектурой.
Вот этот переходный этап в некоторых случаях зависит от того как должно выглядеть приложение
По моему, это нормально. Как раз таки когда верхнеуровневая архитектура разработана, можно спускаться ниже и прорабатывать конкретные слои (компоненты, модули). В том числе — механизм взаимодействия с внешним видом.
У меня опыта мобильной разработки мало, так что, возможно, я не совсем в теме, хотя, как мне кажется, общие принципы архитектуры, они едины
При чем тут дизайн? Так ведь эти вещи связаны напрямую. Что будет в основе самого приложения: вкладки внизу или боковая панель с разделами?
По-моему, архитектор не должен брать в расчёт такие детали дизайна, так как они связаны только с отображением, но никак не с архитектурой в целом. Иначе при изменении вкладок на панель, нам нужно будет пересматривать всю архитектуру.
Какие данные нам будет передавать серверная часть? А в каком виде она будет передавать те или иные данные?
Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).
В идеале, дизайн никак не должен зависеть от архитектуры. Есть данные, которые нужно отобразить и которые имеют какой то определённый формат. При изменении внешнего вида, ничего меняться не должно. Это в общем обычный MVC паттерн Вам скажет.
-1
В одной строке вариант написания атрибутов с одной кавычкой (value=''), с двумя (name=«password») и вообще без них (type=hidden)
Ну разделить представление и логику обычно можно, если заранее на это закладываться. Потому что, как я уже писал ранее, представление зависит только от формата данных, а это уже не архитектурное решение. От дизайна может зависеть более низкоуровневая реализация (к кому обратиться за данными, в каком формате вернуть, сколько записей и т.д.), но никак не архитектура.
Понятие не то, что бы широкое, скорее нет чёткого однозначного определения, немного путается с архитектурой.
По моему, это нормально. Как раз таки когда верхнеуровневая архитектура разработана, можно спускаться ниже и прорабатывать конкретные слои (компоненты, модули). В том числе — механизм взаимодействия с внешним видом.
У меня опыта мобильной разработки мало, так что, возможно, я не совсем в теме, хотя, как мне кажется, общие принципы архитектуры, они едины
По-моему, архитектор не должен брать в расчёт такие детали дизайна, так как они связаны только с отображением, но никак не с архитектурой в целом. Иначе при изменении вкладок на панель, нам нужно будет пересматривать всю архитектуру.
Это тоже вряд ли можно отнести к архитектуре, это скорее дизайн (тут я имею в виду не дизайн интерфейса, а некий переходный этап между архитектурой и разработкой, который тоже называется дизайн).
В идеале, дизайн никак не должен зависеть от архитектуры. Есть данные, которые нужно отобразить и которые имеют какой то определённый формат. При изменении внешнего вида, ничего меняться не должно. Это в общем обычный MVC паттерн Вам скажет.
Всё это, конечно, сугубо моё мнение.
Что мотивирует Вас использовать такие названия таблиц?