Я конечно никакой не руководитель, но все же не согласен с таким подходом. Нужно как минимум не меньше внимания уделять знаниям кандидата, чем всему остальному. Ведь часто на словах он Лев Толстой, а на деле… Я бывал на некоторых собеседованиях, на которых у кандидатов были определенные пробелы в знаниях, но вроде бы огромное желание, жизненная позиция и далее по списку из статьи. Я тогда своему начальнику посоветовал дать тестовое задание. Он не послушал, «повелся» на желание и рассказы. Ничего хорошего из этого не вышло. Много идей, но мало возможностей их реализовать и сделать что-то осмысленное. В результате была набрана целая команда вот таких товарищей, которые идеи генерировали в гораздо большем количестве, чем работающий код. Бывало такое что они делали 2 недели одно, потом у них возникала другая «идея» и 2 недели работы пропадали, потому что нужно было переделывать по-другому.
Создатель автомобиля не использовал свое колесо. Создатель интернета не открывал свое электричество. Создатель любого языка программирования не изобретал интегральную схему. Значит все это не инновации?
Автор же не предлагает все силы бросать на изобретение велосипеда, что в случае провала приведет к нищете, а выделять для этого определенное количество времени. Как по мне даже если твой велосипед не станет лучше уже существующего, все равно это не время потраченное впустую, это ценный опыт, это интересно. В одной из статей про iOS разработку писалось что 85% приложений не окупают себя. Если рассуждать с этой точки зрения, то можно сказать себе: в AppStore и так много приложений, зачем что-то изобретать, скорее всего это не принесет мне ничего.
С SecureString не хочется связываться, потому что для дешифрации пароля нужно работать с неуправляемыми типами данных. Во втором варианте вы предлагаете избежать хранения пароля в открытом виде в классе PasswordBehavior вашего примера (т.к. он будет дешифроваться с помощью интерфейса), но после биндинга к свойству ViewModel он опять же будет храниться в открытом виде. Биндинг который в конечном итоге работает со свойством PasswordBox.Password нельзя использовать вообще.
Как вариант элементы главного View можно сгрупировать в отдельные UserControl-ы и перенести логику связанную с ними в соответствующие ViewModel-ы, которые будут в виде свойств в главном ViewModel.
Суть описанного метода состоит в том, чтобы не хранить пароль в открытом виде ни в каком из объектов, а получать его по требованию. В вашем же примере пароль будет находится в VM все время пока существует сама VM.
Спасибо, рецензию я читал, а вот книгу пока еще нет. В моем случае действительно можно было сразу передать интерфейс в VM и тогда unity в самом VM вообще не нужен. Я описал более общий подход, который можно использовать в разных сценариях. Например, если ViewModel и View создаются в разных местах, или же View вообще явно не создается, а биндится в ресурсах:
Кроме того, если нет необходимости выполнения команды Login а нужно просто получить данные из контрола и сохранить, например, в конфиг, то к паролю вообще нет доступа.
В этом случае передать интерфейс в VM нет возможности.