Это действительно зависит от того, где вы счастливы, имея зависимости от EF4.1.
Если это просто вещь для доступа к данным - тогда хранилище.Это при условии, что ваши POCO преднамеренно очищены от ненужных зависимостей и являются структурами данных, которые будут передаваться между слоями.
Edit
Итак, вынужно подумать об ответственности и зависимостях.
Когда Скотт Миллетт (или кто бы то ни было) придумал 7 проектов, он / они заявили, для чего каждый из них был?Если они сделали это, то должны дать хотя бы часть вашего ответа: если вы думаете о том, что EF делает для вас (или для чего вы собираетесь его использовать), в отношении целей каждого проекта.
Одна вещьэто не сразу очевидно, где живет бизнес-логика - я предполагаю, что это модель.Суть бизнес-логики в том, что вы, возможно, захотите многократно использовать ее.При повторном использовании вполне вероятно, что контекст повторного использования будет отличаться от текущего.
Опасность заключается в том, что эти разные контексты могут иметь очень разные технические ограничения - в таких случаях вы хотите иметь как можно меньше зависимостей;когда вы зависите от чего-то (например, от EF), вы также зависите от того, от чего это зависит.Если ваша модель EF зависит от SQL (например), тогда ваша логика связана с SQL.
Кроме того, может возникнуть проблема с автогенерацией - если вы когда-нибудь решите, что вам не нужно что-то генерировать автоматически.
Лично я, вероятно, хотел бы создать свои собственные POCO для прохода между слоями и использовать EF исключительно в репозитории.