Последние два с половиной года я использую linq для сущностей в производственных приложениях, и могу сказать, что это был действительно приятный опыт ... но это не значит, что вы должны делать все с Linq.
Я постараюсь дать вам несколько ответов на ваши вопросы,
Я думаю, вам следует сначала спросить , какое приложение вы хотите создать ; когда сценарий прояснится, у вас будет странное представление о количестве транзакций или запросов, которые вы собираетесь выполнить с базой данных (или хранилищем).
Linq может быть чрезвычайно полезен для абстрагирования доступа к данным, обработки контекста и сущностей, но все идет за деньги. Объекты будут создаваться со стоимостью, и вам действительно нужно подумать об этом.
Если ваше приложение имеет «красивый, но не слишком сложный» доступ к данным, Linq будет идеальным инструментом для экономии времени для вашего приложения.
Если ваше приложение целиком основано на извлечении или обработке данных, Linq также подойдет.
Если ваше приложение обрабатывает огромные блоки данных (проверьте ваше приложение), вам нужно будет сделать что-то еще, чтобы избежать создания группы объектов, которые могут оказаться бесполезными.
Что это значит? Вам необходимо знать, что означает интеллектуальный доступ к данным ... и это позволяет SQL работать на вас (в случае SQL); если вы собираетесь выполнять множество операций объединения, перекрестной информации и прочего, создайте хранимые процедуры, которые создадут для вас результат данных, а затем получите его с помощью Linq или SqlCommand или SqlDataAdapters и т. д. *
Что наносить на какой слой?
Поскольку Linq предоставляет вам абстракцию доступа к данным, вы можете в значительной степени разместить свой код там, где этого требует бизнес-логика. Существует множество примеров того, как структурировать ваш код; Linq (как любая другая структура сущностей или библиотеки доступа к данным) подойдет в нужном месте.
Избегайте, когда это возможно, прямого выражения linq в ваших элементах управления (asp.net имеет много элементов управления с источниками данных linq), вместо этого оберните ваш «запрос» классом обслуживания, который может быть создан вашим кодом или элементами управления в качестве источника данных объекта.
Что я нашел?
Чистый Linq не всегда возможен в больших приложениях или проектах (так что в конечном итоге вы получите много вещей в linq, а некоторые в предыдущих более простых решениях для доступа к вашим репозиториям), но это поможет вам сэкономить время.
Реализация хранимых процедур ОБЯЗАНА, если вы хотите предоставлять приложения высокого качества.
Надеюсь, этот комментарий поможет.
Приветствия.