Михаил снова здравствуйте! В-общем, меньше слов - больше кода.
Toster_q187249.zip - здесь архив с приложением. Предметную область смоделировал так, как понял :)
Честно говоря, ни разу не слышал фразы "доменная модель". Откуда этот термин? Обычно для описания данных используются термины "данные", "модель".
Далее: прочтите
от корки до корки книжку "
ASP.NET MVC 3/4 Framework с примерами на C# для профессионалов", авторы:
Адам Фримен, Стивен Сандерсон. Для MVC - на мой взгляд, это книга №1 для изучения ASP.NET MVC. Там есть всё, что нужно, и даже больше. У Вас, правда, могут возникнуть трудности с Entity Framework, потому что там они не так подробно объясняют, как с ним работать, (авторы, наверное, рассчитывают на небольшой опыт работы читателей с этим фреймворком). После чтения у Вас в голове всё встанет на свои места.
Будут какие-то вопросы по проекту - пишите. Он, конечно, примитивный, но в целях обучения, на мой взгляд, подойдет.
Вы, наверное, уже знаете, но, тем не менее, напишу: в контроллере должно быть минимум бизнес логики.
Контроллер должен лишь получать откуда-то данные, формировать из них
модель представления и отдавать модель представления в само
представление. Всю логику работы с данными следует выносить в отдельный слой (например, в отдельную dll). Всю бизнес-логику, по хорошему, тоже следует выносить в отдельный слой. В итоге контроллеры MVC-приложения должны "ломиться" в слой бизнес-логики, который в свою очередь, ломится в слой работы с данными, вытаскивает их, обрабатывает и отдает "наверх" в клиентское приложение (MVC-application). Это позволяет формировать трехуровневую ахитектуру решений и тем самым создавать более масштабируемые и гибкие приложения.
Например, то приложение, которое я Вам прислал, состоит их 2 слоев:
1) MVC-app;
2) Core.DAL - слой работы с данными.
В идеале следовало бы добавить новый слой (например, Core.BL или Core.BAL) - слой бизнес-логики.
Вот на всякий случай:
Как организовать архитектуру приложений «Система управления проектами»?
Успехов в нашем нелегком деле!
