Я помещаю свои сущности, DbContext (s) и классы репозитория в отдельную сборку (домен) и ссылаюсь на нее из моих веб-приложений. Если это было достаточно маленькое приложение, то папка «Домен» в веб-приложении, безусловно, достаточно разделена. Это строго ради организации.
Что я не рекомендую, так это пытаться извлечь все из абстракций от Entity Framework. Это включает в себя большое количество относительно сложного кода или жертвует производительностью и возможностями, которые EF может предоставить вашему проекту.
Например, в моем случае и веб-проект, и сборка домена будут содержать ссылки на EF. Это потому, что мои классы репозитория возвращают IQueryable<TEntity> в своих методах, и мой контроллер также отвечает за единицу работы, которая будет связывать DbContext. Чтобы использовать это, веб-проекту потребуется ссылка на EF. Я видел многочисленные попытки абстрагировать EF так, чтобы веб-проекты не нуждались в ссылке на Entity Framework. ИМХО, это огромная трата усилий на сложный код или жертвы настолько, что EF может сделать для проекта. Например, вы можете ввести сложные параметры, такие как Func<Expression<T>>, чтобы выполнить фильтрацию, а затем вам также нужно беспокоиться о сортировке выражений, разбивке на страницы, быстрой загрузке и т. Д. c. Или вы покончили с гибкостью и производительностью возможности сокращать EF-запросы, основываясь только на том, что нужно обстоятельствам, благодаря тому, что ваши классы сборки домена (службы или репозитории) возвращают DTO или отдельные объекты. Это приводит к большому количеству шаблонного кода и / или значительным ошибкам в производительности.
Короче говоря, при рассмотрении вопроса о том, разбивать ли функциональность на отдельную сборку или нет, важно взглянуть на причины нежелания сделать это. В целом, стремление к простоте - лучший совет, который я могу дать.