Я нахожусь в процессе определения довольно простой многоуровневой архитектуры для приложения .NET MVC, которое имеет уровень хранилища и уровень обслуживания. Я нашел несколько довольно четких и простых примеров, особенноwww.asp.netи некоторые вопросы и ответы здесь, но я ищу что-то более простое, подходящее для небольших приложений, но использующее различные проекты, чтобы донести идею. В примере, на который я ссылался выше, хранилище и служба являются классами в пространстве имен Models. Это просто неМне не хватает четкого разделения, чтобы я мог правильно это проиллюстрировать.

У меня есть отдельный проект для репозитория, который реализует интерфейс IRepository. Для Службы существует отдельный проект, который реализует IService и использует IRepository (внедрение конструктора). Сервис реализует IService. Для этого примера достаточно того, что контроллер создает экземпляр службы, пока нет необходимости в контейнере IoC. Думайте об этом как о промежуточном шаге к пониманию лучших архитектурных практик, части последовательности, которая постепенно строится, чтобы включать внедрение зависимости и, возможно, больше слоев.

Вопрос в том, где я должен определить IRepository и IService? Конечно, и сервисные, и репозиторные проекты должны ссылаться на них. Тогда очевидно, что они должны быть определены в другом проекте, на который ссылаются как сервисы, так и проекты репозитория. Если да, то каким будет хорошее соглашение об именах? Что-то вроде XXXXContracts?

Аналогично, для моделей данных, передаваемых между уровнями представления, обслуживания и хранилища, допустимо ли иметь отдельный проект под названием XXXXModels, на который ссылаются все уровни? Я понимаю, что в некоторых случаях модели, передаваемые между уровнем службы и хранилищем, могут отличаться от моделей, передаваемых между уровнем службы и уровнем представления, но принцип тот же.

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