Ответ 1
Вот быстрый проект того, что я попробую... Я бы создал следующие слои:
- Contoso.Core(библиотека классов)
- Contoso.Data(библиотека классов)
- Contoso.Service(библиотека классов)
- Contoso.Web.Framework(библиотека классов)
- Contoso.Web(ASP.NET MVC 5.0)
Contoso.Core:
Этот слой содержит все мои объекты/классы, представляющие мои TABLES базы данных.
Итак, например, у меня будет:
- Класс User.cs.
- Класс Product.cs
- Класс ProductDetail.cs
- Etc..
Некоторые люди называют эти объекты/классы: объекты домена, другие называют его классами POCO.
Либо либо, либо эти сущности/классы определены в основном слое, так как они могут (или не могут) использоваться среди других слоев.
Contoso.Data:
Этот слой определяет класс ContosoDbContext.cs
. Внутри этого файла есть все мои DbSet<>
.
Так, например, у меня было бы следующее внутри ContosoDbContext.cs
:
- общедоступный пользователь DbSet {get; задавать; }
- общедоступный продукт DbSet {get; задавать; }
- общедоступный DbSet ProductDetail {get; задавать; }
Излишне говорить, что на слое Contoso.Data будет DEPENDECY на уровне Contoso.Core
.
Кроме того, внутри слоя Contoso.Data
у меня будет свой общий репозиторий и все, что связано с "доступом к данным".
Contoso.Service:
Этот слой будет содержать все мои бизнес-правила. Например, у меня может быть класс UserService.cs
, который может иметь метод Login()
. Метод Login() получит имя пользователя/пароль и вызовет репозиторий для поиска пользователя.
Поскольку для уровня сервиса нужен репозиторий, у меня будет ЗАВИСИМОСТЬ на уровне Contoso.Data
И потому, что я буду играть с классом User (который живет внутри слоя Contoso.Core
), Я ТАКЖЕ ИМЕЕМ ЗАВИСИМОСТЬ на уровне Contoso.Core
.
Contoso.Web.Framework:
Этот уровень будет иметь зависимость от Contoso.Core
, Contoso.Data
и Contoso.Service
.
Я бы использовал этот слой Contoso.Web.Framework
для настройки моей инъекции зависимостей.
Contoso.Web:
Последний уровень, приложение MVC 5.0, будет иметь зависимость от Contoso.Web.Framework
AND на Contoso.Service
и на Contoso.Core
.
Контроллеры будут ссылаться на методы, живущие внутри классов, определенных на вашем уровне Contoso.Service
(например, метод Login()).
Метод Login() может, например, возвращать класс пользователя (нулевой или заполненный), а также потому, что он возвращает класс пользователя, и, поскольку мы находимся внутри контроллера, наш уровень Contoso.Web
нуждается в зависимости от Contoso.Service
и Contoso.Core
.
Конечно, я не детализировал все здесь или каждый слой, но это просто, чтобы дать вам пример типа использования идентификатора архитектуры.
До сих пор я не ответил на ваш вопрос, но мало что знаю о MVC 5.0 и его новом механизме Identity, я считаю, что слой Contoso.Core
должен был бы иметь зависимость от Microsoft.AspNet.Identity.EntityFramework
в дополнение к Microsoft.AspNet.Identity.Core
Аналогично, моему классу ContosoDbContext.cs
необходимо реализовать интерфейс IdentityDbContext
, который, как оказалось, принадлежит Microsoft.AspNet.Identity.EntityFramework.dll
.
Это означает, что мой слой Contoso.Data
будет иметь зависимость от Microsoft.AspNet.Identity.EntityFramework
и, скорее всего, Microsoft.AspNet.Identity.Core
...
Как вы говорите, при создании нового проекта MVC 5.0 все это существует и определяется в рамках одного приложения. Ничего нет или не было разделено на слои. Таким образом, в приведенной выше архитектуре класс ContosoDbContext.cs
живет внутри слоя Contoso.Data
и НЕ непосредственно внутри приложения ASP.NET MVC.
Так как я еще не пробовал новую идентификацию ASP.NET, и я не пытался разобрать вещи, я бы не знал, как честно ответить на ваш вопрос. Я думаю, вам придется попробовать и переместить вещи.
Если и когда вы это сделаете, не стесняйтесь рассказывать нам, как это происходило, и каковы вещи/проблемы, с которыми вы столкнулись.
Между тем, надеюсь, это помогло вам пролить свет (или нет).
Винс