Антон Папин

Модель в MVVM не должна содержать никаких данных. Данные нужны для отображения во View, соответственно они получаются и используются во ViewModel.

Model представляет собой модель некой сущности (как правило таблицы БД) и должна состоять в основном из методов манипуляции данными.

Например:
UserModel - методы для создания, удаления, редактирования и получения одного или списка пользователей.
UserViewModel - хранение списка пользователей, либо хранение данных полей пользователя, команды для получения данных из модели, в том числе здесь могут быть и автономно запускающиеся (например по таймеру).

Смотреть код?

Всегда использовать. Просто - всегда. WPF изначально разработан под связывание и нормальную архитектуру.

То, что можно делать так же, как в WinForms, не говорит о том, что это стоит делать.

Просто запомнить как мантру, создал проект - добавь референс на MVVM фреймворк, и работай. Фреймворк любой, например MVVMLight. Или Prism. Или свой велосипед (я так делаю), любой.

Binding для PasswordBox не реализован вполне намеренно, чтобы не было так просто перехватить пароль, введённый в поле.

В качестве стандартной и относительно безопасной практики, часто пользуюсь передачей PasswordBox-а в команду логина параметром.

<TextBox Text="{Binding Login}" x:Name="TbxLogin" />
<PasswordBox x:Name="PasswordBox" />
<Button Content="Log in" Command="{Binding SigninCommand}"
		CommandParameter="{Binding ElementName=PasswordBox}" IsDefault="True" />

public ICommand SigninCommand { get; set; }
private void Signin(object param)
{
	var passwordBox = param as PasswordBox;
	if (passwordBox == null)
		return;
	var password = passwordBox.Password;
        ...
}

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

Пример:

Модель:

namespace MyApp.MyNamespace.ViewModels
{
	public class MyWindowModel : INotifyPropertyChanged
	{
	   private object _foo;
	   public object Foo
	   {
		  get { return _foo; }
		  set { _foo = value; RaisePropertyChanged("Foo"); }
	   }

	...

	}
}

Вьюшка:

<Window x:Class="MyApp.MyNamespace.MyWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:viewModels="clr-namespace:MyApp.MyNamespace.ViewModels">
   <Window.DataContext>
      <viewModels:MyWindowModel x:Key="Model" />
   </Window.DataContext>
   <Grid>
      <TextBlock Text={Binding Foo} />
   </Grid>
</Window>

Вызывать можно так, например как вы говорите из окошка логина:

...
// проверяем успешность логина
if (!loginSuccess)
	return;

// если всё хорошо, то создаём новое окно
var myWindow = new MyWindow();

// если нужно - что-то делаем с моделью внутри окна
var model = myWindow.DataContext as MyWindowModel;
model.Foo = new object();

// показываем новое окно
myWindow.Show();

// закрываем текущее окно логина
var window = Application.Current.Windows[0];
if (window != null)
	window.Close();

Getting GPS data from an image's EXIF in C#

Ну, кроме того, что вы используете plain sql в коде в XXI веке, вместо того, чтобы использовать одну из замечательных ORM,

вы забыли, что в таких операциях полезно в начало скрипта вставить SET DATEFORMAT

Однако, я всё ещё настойчиво рекомендую использовать ORM. Entity Framework, NHibernate, или любой другой на ваш вкус.

Для windows 8 можно использовать modern приложения. Они также поддерживают тачскрин. К тому же их проще портировать для мобильных ОС.

Лучше вернуть OperationResult в обоих случаях, например такой:

public class OperationResult<T>
{
     T Result { get; set; }
     string Message { get; set; }
     bool IsSuccessful { get; set; } // можно заменить на enum с бОльшим количеством вариантов
}

Говнокод.ру полагаю :)

А если серьёзно, то мне помогли книжки по паттернам программирования и хорошему коду. Правда не сразу - года через три. Поначалу только мешали :)

Покажите код и можно будет придумать решение.

Книжка Microsoft в соавторстве с intuit, C# для школьников - отличное начало.

А потом Троелсен.

Атрибуты - это метаданные вашего кода. Они "работают" в основном на этапе компиляции, превращаясь в типовые конструкции в выходном IL. Использовать run-time переменные в атрибутах просто некорректно.

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

Не очень понимаю, зачем вам асинхронный геттер.

Сделайте в модели асинхронный метод, который получает значение и заносит его в поле, связанное с UI. Метод можно вызывать в конструкторе, или по таймеру, или через команду - как нужно.

Если не нравится, что пока идёт загрузка, в UI показывается значение по умолчанию - тут уже варианты, от банального FallbackValue при связывании до конвертеров и кастомных полей (как-то для такой цели я сделал поле модели типа string, при асинхронной загрузке заносил туда значение типа "loading...", а после успешной загрузки клал туда отформатированное в string значение).

Когда ваш проект находится под управлением TFS и он не в состоянии checked out, то все файлы проекта помечаются атрибутом read only. Если нет соединения с TFS, перезапустите студию и она будет предлагать снять атрибут при обращении к файлу.

Атрибут можно снять ручками в свойствах файла в обычном проводнике, но могут быть проблемы с неучтёнными изменениями при check-in.