Причина в валидации через атрибуты (дальше по тексту). Они удобнее. Они должны быть для полей, поля находятся в файле, который генерируется, туда доступа мы не имеем (т.е. редактировать там чревато, при повторной генерации наш код пропадет). Поэтому и AutoMapper.
Да, я согласен, что не очевидно. Для этого я добавил исходники, т.е. если пробовать их запускать, и сравнивать, то можно найти как это работает. По поводу второго — там дальше есть по тексту инициализация, возможно в первых редакциях этот абзац был выше, а потом я не уследил.
Я исправил текст, чтобы это стало очевидно. Если в дальнейшем будут еще какие-то подобные случаи, то сообщите мне, я их буду править.
О! Круто что разобрались. Я думал, что слишком сложно написал, никто не поймет.
По поводу кодировки файлов — я просто не заметил. И скаффолдинг написал до того как начал пользоваться bootstrap`ом, а когда переписал, не заметил и не добавил.
Я немного запутался, какой автор — это я, а какой автор — это Seemann Mark.
Я просто расскажу, как я считаю. Если вы пишете приложение, то можно обойтись без DI, изначально. Но потом — ближе к глобальным изменениям проекта наступает кризис. Мы изменяем что-то. Другой программист изменяет что-то. И всё перестает работать. Надо тестирование. Для тестирования необходим DI. В некоторых случаях этот момент может и не произойти. Вы сделали проект, его оплатили (или не оплатили) и всё это DI-использование повисло в воздухе. Оно не сыграло свою положительную роль. Мои проекты доживают до стадии глобальных изменений. DI мне нужен, заказчики платят деньги. Все довольны.
Но (!) возможно Seemann Mark пошел дальше, он участвовал в проекте и в какой-то неясной ситуации достиг критической точки. И сидя дома в думах понял глобальную ошибку — «не надо было использовать Service Locator». И написал по этому поводу книгу.
Я не отношусь к тому типу людей, которые говорят: «Это используйте, это хорошо. Это не используйте, это плохо». Я думаю, что важно знать инструменты и уметь оценивать риск их использования, и соответственно применять.
Изначально пользовался им, но когда дошло дело до статей, рассмотрел и другие IoC-контейнеры. Пользовался еще на чужом проекте Unity, но Ninject просто лучше знаю. По производительности, удобству — не сравнивал.
1. Добавляете в Language таблицу язык de | Deutsch
2. Берете любой понравившийся GlobalRes.resx и ctrl-c и в Excel ctrl-V
3. Переводчик переводит эти ресурсы (второй столбец только)
4. Вы создаете GlobalRes.de.resx (не забывая про Properties) и ctrl-v из переведенного Excel файла
5. Даете доступ переводчику в админку и он переключает язык в Deutsch и переводит раз за разом все статьи/новости
6. Всё
Суть Service Locator — развязать зависимости модулей.
Зачем это нужно? У нас есть границы модуля. Например примерно так будет выглядеть стандартное MVC приложение:
На контроллер завязано много связей, что делать чтобы проверить его работоспособность? Мы должны запустить как-то код. И тут два варианта: или это будет тестер за компьютером, или мы будем проверять программно.
Чтобы проверять программно, мы должны все окружающие его модули. Т.е. всё окружение мы меняем на объекты-заглушки: HttpContext, IRepository, Mail, SmsProvider и др. Т.е. всё окружение — это не реальные модули, а декорации.
Для чего это надо? Если мы снимаем фильм, легче снимать в павильоне, мы восстанавливаем комнату и актеры дубль за дублем играют роль. Если необходима уличная съемка — мы или восстанавливаем в павильоне часть улицы или выходим на улицу. Иногда декорации могут быть дорогостоящие, как в «Шоу Трумена», чтобы актер мог лучше сыграть. Тестирование объекта (в нашем случае контроллера) — это и есть проигрывание сценария.
Если инициализация (вызов конструктора) будет находится в самом контроллере мы не сможем заменить реальное окружение на декорации не изменяя кода. Для этого мы и используем Service Locator.
Больше его суть раскрывается в уроке E, где мы активно начинаем использовать mock-объекты, переделываем NotifyMail (из урока A) под сервис и используем интегрированное тестирование (где тестируем и реальный код SqlRepository).
Просто частая ошибка, когда отсутствует или сам скаффолдер (а IRepository в webTemplate.Model находится), или нет класса с которым ему нужно работать (не сохранен webTemplateDb.dbml).
Есть и другие конечно.
1. Должна быть создана таблица (Например Class1)
2. Она должна быть перенесена в webTemplateDb.dbml и файл должен быть сохранен
3. В PackageManager должен быть выбран проект webTemplate.Model
Не рекомендуется, но не запрещено. И я старался в учебных материалах кратко давать решение (тем более что в данном случае оно не существенно), чтобы экономить место и так в такой простыне.
На самом деле целей было несколько:
Первое, это организовать наработки. Т.е. все удачные решения — собрать в одном месте.
Второе, справочник. Как-то поймал себя на том, что решая проблему вышел на собственную статью ранее написанную. Так как хабр всегда под рукой, я смогу пользоваться собственными знаниями в будущем.
Третье, это открыть свои знания. Чем больше статей, тем легче получить нужные знания, тем больше разработчиков в этой области, тем проще работать, и опять же тем больше статей. Да, и технология живет за счет людей, которые ею пользуются.
Четвертое, я хочу найти и обучить помощника, потому что заказов много и я не справляюсь. Каждому объяснять — сложно. Лучше один раз написать и давать ссылку.
Я исправил текст, чтобы это стало очевидно. Если в дальнейшем будут еще какие-то подобные случаи, то сообщите мне, я их буду править.
В данный момент статья не особо актуальна, так как гугл-мапс выпустили новую версию API. Исследуйте в примерах.
По поводу кодировки файлов — я просто не заметил. И скаффолдинг написал до того как начал пользоваться bootstrap`ом, а когда переписал, не заметил и не добавил.
Я просто расскажу, как я считаю. Если вы пишете приложение, то можно обойтись без DI, изначально. Но потом — ближе к глобальным изменениям проекта наступает кризис. Мы изменяем что-то. Другой программист изменяет что-то. И всё перестает работать. Надо тестирование. Для тестирования необходим DI. В некоторых случаях этот момент может и не произойти. Вы сделали проект, его оплатили (или не оплатили) и всё это DI-использование повисло в воздухе. Оно не сыграло свою положительную роль. Мои проекты доживают до стадии глобальных изменений. DI мне нужен, заказчики платят деньги. Все довольны.
Но (!) возможно Seemann Mark пошел дальше, он участвовал в проекте и в какой-то неясной ситуации достиг критической точки. И сидя дома в думах понял глобальную ошибку — «не надо было использовать Service Locator». И написал по этому поводу книгу.
Я не отношусь к тому типу людей, которые говорят: «Это используйте, это хорошо. Это не используйте, это плохо». Я думаю, что важно знать инструменты и уметь оценивать риск их использования, и соответственно применять.
2. Берете любой понравившийся GlobalRes.resx и ctrl-c и в Excel ctrl-V
3. Переводчик переводит эти ресурсы (второй столбец только)
4. Вы создаете GlobalRes.de.resx (не забывая про Properties) и ctrl-v из переведенного Excel файла
5. Даете доступ переводчику в админку и он переключает язык в Deutsch и переводит раз за разом все статьи/новости
6. Всё
Зачем это нужно? У нас есть границы модуля. Например примерно так будет выглядеть стандартное MVC приложение:
На контроллер завязано много связей, что делать чтобы проверить его работоспособность? Мы должны запустить как-то код. И тут два варианта: или это будет тестер за компьютером, или мы будем проверять программно.
Чтобы проверять программно, мы должны все окружающие его модули. Т.е. всё окружение мы меняем на объекты-заглушки: HttpContext, IRepository, Mail, SmsProvider и др. Т.е. всё окружение — это не реальные модули, а декорации.
Для чего это надо? Если мы снимаем фильм, легче снимать в павильоне, мы восстанавливаем комнату и актеры дубль за дублем играют роль. Если необходима уличная съемка — мы или восстанавливаем в павильоне часть улицы или выходим на улицу. Иногда декорации могут быть дорогостоящие, как в «Шоу Трумена», чтобы актер мог лучше сыграть. Тестирование объекта (в нашем случае контроллера) — это и есть проигрывание сценария.
Если инициализация (вызов конструктора) будет находится в самом контроллере мы не сможем заменить реальное окружение на декорации не изменяя кода. Для этого мы и используем Service Locator.
Больше его суть раскрывается в уроке E, где мы активно начинаем использовать mock-объекты, переделываем NotifyMail (из урока A) под сервис и используем интегрированное тестирование (где тестируем и реальный код SqlRepository).
Есть и другие конечно.
2. Она должна быть перенесена в webTemplateDb.dbml и файл должен быть сохранен
3. В PackageManager должен быть выбран проект webTemplate.Model
И всё получится
Первое, это организовать наработки. Т.е. все удачные решения — собрать в одном месте.
Второе, справочник. Как-то поймал себя на том, что решая проблему вышел на собственную статью ранее написанную. Так как хабр всегда под рукой, я смогу пользоваться собственными знаниями в будущем.
Третье, это открыть свои знания. Чем больше статей, тем легче получить нужные знания, тем больше разработчиков в этой области, тем проще работать, и опять же тем больше статей. Да, и технология живет за счет людей, которые ею пользуются.
Четвертое, я хочу найти и обучить помощника, потому что заказов много и я не справляюсь. Каждому объяснять — сложно. Лучше один раз написать и давать ссылку.