Как организовать архитектуру приложений «Система управления проектами»?

В целях обучения делаем систему управления проектами по типу Pivotal или Jira. Используем .NET C#, Entity Framework.

Требования:
- REST API веб-сервис
- Клиент для Windows
- Web-клиент
- Клиенты для мобильных устройств (Windows Phone)
- По скольку проект учебный, есть упрощенный вариант для WPF - работа с данными без веб-сервера (исп. MVVM)

Вопросы:
- Из каких слоев должна состоять такая система?
- Что должно находиться в каждом слое?

Сейчас я понимаю, что должен быть слой доступа к данным (DAL). Что должно быть внутри него? Какие интерфейсы в конечном итоге должен предоставлять DAL?
- Сгенерированные модели и DbContext(-ы)?
- Репозиторий(и)?
- В случае если WPF клиент работает напрямую с DAL без сервера, как должны выглядеть репозитории для использования MVVM? Можно ли будет выполнять привязку к методам?
- Чем руководствоваться, создавая больше одного контекста и/или репозитория?

Изучая .NET, вижу большое количество различных видов проектов (ASP.NET, MVCx, WCF). Хотелось бы знать всю эту терминологию и современные тренды в сфере .NET.
  • Вопрос задан
  • 4915 просмотров
Решения вопроса 2
effetto
@effetto
.Net разработчик
При решении поставленной задачи я рекомендую Вам использовать трехслойную архитектуру.

Слой представления в Вашем случае - это windows клиент и web клиент.
Слой домена - это сами объекты предметной области и веб сервисы.
Слой данных - это маппинг предметной области в бд.

Слой данных рекомендую организовать на основе Entity Framework 7 (бета), так как последняя версия поддерживает внедрение зависимости. Для учебного проекта будет в самый раз, заодно изучите новую технологию.

Для предоставления данных рекомендую использовать шаблон Factory и шаблон Репозиторий.

WPF клиентов я рекомендую цеплять все равно через сервисы, чтобы не нарушать общую архитектуру. Visual Studio сама сгенерирует Вам классы-обертки для вызова сервисов. К их методам Вы уже можете привязываться.

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

Для пополнения копилки знаний на тему проектирования ПО я настоятельно рекомендую к прочтению Мартина Фаулера - Шаблоны корпоративных приложений. Ответы почти на все Ваши вопросы имеются в данной книге.
Ответ написан
Комментировать
Valeriy1991
@Valeriy1991
Разработчик .NET C# (ASP.NET MVC) в Alfa-B, Moscow
Добрый день!

Хотелось бы добавить про контексты 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, то все изменения коснутся только слоя доступа к данным.
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы