Как организовать архитектуру приложений «Система управления проектами»?
При решении поставленной задачи я рекомендую Вам использовать трехслойную архитектуру.
Слой представления в Вашем случае - это windows клиент и web клиент.
Слой домена - это сами объекты предметной области и веб сервисы.
Слой данных - это маппинг предметной области в бд.
Слой данных рекомендую организовать на основе Entity Framework 7 (бета), так как последняя версия поддерживает внедрение зависимости. Для учебного проекта будет в самый раз, заодно изучите новую технологию.
Для предоставления данных рекомендую использовать шаблон Factory и шаблон Репозиторий.
WPF клиентов я рекомендую цеплять все равно через сервисы, чтобы не нарушать общую архитектуру. Visual Studio сама сгенерирует Вам классы-обертки для вызова сервисов. К их методам Вы уже можете привязываться.
Более одного контекста нужно создавать когда у Вас имеется гетерогенная структура источника данных. Лучше при проектировании проекта с нуля избегать такой ситуации. Однако во взрослых проектах рано или поздно появляются дополнительные контексты.
Для пополнения копилки знаний на тему проектирования ПО я настоятельно рекомендую к прочтению Мартина Фаулера - Шаблоны корпоративных приложений. Ответы почти на все Ваши вопросы имеются в данной книге.
Добрый день!
Хотелось бы добавить про контексты EF: stackoverflow.com/questions/9415955/c-sharp-workin...
Поясню: когда я впервые столкнулся с масштабным применением EF, в том проекте использовался класс, в котором в виде поля объявлялся контекст. Т.е. контекст EF существовал все время, пока существовал этот класс (DataService). Так вот: все было хорошо до тех пор, пока не пришлось заняться ускорением работы приложения. И обнаружилось, что такой подход практически не позволяет использовать библиотеку TPL (Task Parallel Library), т.к. постоянно возникали ошибки, связанные с тем, что "контекст уже открыт". Ни в коем случае не используйте контекст EF по паттерну "Одиночка" и в статическом классе - наберетесь больших проблем и замучаетесь исправлять ошибки. Исходя из своего опыта (а также опыта моих коллег и друзей), пока что самым удачным применением EF является (как и написано в статье) использование контекста с коротким жизненным циклом, т.е. написали метод (который, например, получает список городов из БД и который, соответственно, будет внутри слоя доступа к данным), внутри инициализируем контекст (лучше с помощью using), получаем данные, оборачиваем их в модель (если надо), закрываем контекст и возвращаем данные наверх.
P.S. Хотелось бы также порекомендовать Вам НЕ работать с классами, генерируемыми EF, в слое бизнес-логики, а писать для этих классов обертки (модели). В одном из проектов, которыми я занимался, используется WPF + MVVM + IoC (Unity Container), и в нем же весь интерфейс биндится к классам EF... Поверьте, это ужасно. Лучше сразу проектируйте так, чтобы классы EF у Вас использовались только внутри слоя доступа к данным, а наверху (в бизнес логике) вся работа ведется с классами-обертками над классами EF (т.е. чтобы классы слоя бизнес-логики ничего не знали о классах EF). В этом еще и такой плюс, что если Вы по каким-либо причинам решите отказаться от EF и перейти, например, на NHibernate или Native Sql, то все изменения коснутся только слоя доступа к данным.