Я задавался вопросом, если установка значения по умолчанию для SelectList считается логикой представления или бизнес-логикой? Например, если требование - то, что Сотрудник не может быть сохранен без Местоположения, но 99% времени, местоположение, которое было бы выбрано, является конкретным объектом - заявляет Атланта. Из-за этого местоположение SelectList должен быть принят значение по умолчанию в Атланту, когда когда-либо экран записи для нового сотрудника отображен. Я должен принимать значение по умолчанию местоположение в модели или в модели представления? Одна вещь, которую я понял, состоит в том, что модульные тесты становятся неловкими, потому что в обоих случаях, я был бы вынужден протестировать против местоположения, которое будет всегда присутствовать в производстве, но я не могу создать модульный тест со своими собственными данными тестирования, если "Атланта" не была в наборе местоположений, используемых в тесте. Я был бы greatful, если у Вас есть какие-либо мысли об этом также.
Как и на многие подобные вопросы (субъективные), ответ будет: «Это зависит».
Если «значение по умолчанию» является бизнес-значением по умолчанию (скажем, местоположение по умолчанию для местоположения компании) , или количество единиц по умолчанию в заказе или что-то в этом роде), вероятно, это бизнес-уровень. Это кажется правильным для вашей конкретной ситуации здесь.
Однако, если "значение по умолчанию" вашего списка просто потому, что вам нужно какое-то значение по умолчанию, и вы просто собираетесь выбрать индекс 0 или просто выбираете на основе местоположения пользователя или системных настроек , Я бы подумал, что это проблемы уровня представления.
Если бы вы были действительно озабочены сохранением границ бизнес-правил и презентационного слоя, вы могли бы предоставить значение по умолчанию через бизнес-логику, а ваш презентационный слой мог бы использовать это значение по умолчанию для инициализации элементов управления.
Из-за этого для SelectList местоположения по умолчанию должно быть установлено значение Location5, когда когда-либо отображается экран ввода для нового сотрудника. Должен ли я использовать местоположение по умолчанию в модели или в модели представления?
В вашем примере это бизнес-логика, но в данном случае это не помешает вам съесть свой торт и съесть его. Модель может указывать значение по умолчанию; затем представление инициализируется этим значением по умолчанию.
В общем, является ли что-то «бизнес-логикой» или «логикой представления», зависит от того, относится ли это к предметной области или нет. Например, установка самого раннего года в раскрывающемся списке даты на, скажем, 1900, вероятно, является проблемой презентации. Но это также может быть проблемой для бизнеса, если система не предназначена для приема дат ранее 1900 года.
Я понял одну вещь: модульные тесты становятся неудобными, потому что в обоих случаях я был бы вынужден тестировать против местоположение, которое всегда будет присутствовать в производстве, но я не могу создать модульный тест с моими собственными тестовыми данными, если только «Атланта» не входит в набор местоположений, используемых в тесте. Я был бы очень рад, если у вас есть какие-либо мысли по этому поводу.
Благодаря стратегии, о которой я упоминал выше, модульное тестирование становится проще. Просто убедитесь, что:
Я бы подумал, что значения по умолчанию - это бизнес-логика.
Например, если компания переезжает, местоположение по умолчанию больше не «Альтанта» или «Лондон», а «Нью-Йорк» или «Ноттингем».