Лучшие практики: 3-уровневая архитектура в LINQ
У меня была такая же проблема с ядром dot net, вот что я сделал:
-Сделайте виртуальный каталог
-Пишите его в этот путь к папке (внутри wwwroot)
- Сделайте ваши fullpath равными этому VD; абсолютный путь (можно сохранить в конфигурационном файле)
-дать разрешения на запись для этой папки в iisuser
4 ответа
Можно думать о LINQ-SQL, поскольку DAL, таким образом с помощью него "непосредственно от бизнес-логики" является не обязательно плохой вещью.
http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-in-linq.aspx имеет некоторые популярные перечисленные подходы L2S.
На нашем проекте мы не хотели раздавать контекст данных, таким образом, мы использовали шаблон, подобный № 3 из вышеупомянутой ссылки (Окружающий DataContext, посмотрите ниже). Это имело некоторые проблемы, но это работало обоснованно хорошо; по крайней мере, для нашего веб-проекта.
Окружающий DataContext (В настоящее время использующий это)
Идея позади окружающей среды datacontext состоит в том, что контекст создается для особого потока или httpcontext (в asp.net), как только существует первый призыв к DataContext. Затем тот же контекст используется для того потока или запроса, если он не расположен вручную. Это сделано путем хранения контекста в хранилище данных запроса/потока. Подход к этому шаблону является аналогичным статическому DataContext, однако, разделение обеспечивается для каждого потока и запросов. Это работает действительно хорошо у Asp. Сеть, однако, снова заполоняется некоторыми проблемами статического контекста.
Проблемы с этим шаблоном:
* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work * Portability across thread is very hard * Unit of work pattern is not transparent enough
Вы могли читать немного на Доменном Управляемом Дизайне.
С практикой Доменного управляемого дизайна (DDD) у Вас есть богатая 'модель предметной области', в том, где Вы выражаете проблемную область, которой Вы хотите заняться. Эта модель предметной области состоит из классов (и структуры), с которым Вы моделируете свои предприятия. Модель предметной области также состоит из репозиториев.
Репозиторий является некоторой абстракцией, которую Вы используете в своей модели предметной области (и в Вашем приложении); репозиторий является абстракцией Вашего хранилища данных. Через репозиторий можно получить объекты, и можно использовать репозиторий для сохранения объектов.
В Вашем случае Ваши Репозитории могли использовать Linq Для SQL внутренне, чтобы говорить с базой данных. Отметьте однако, что Ваш репозиторий не должен быть ответственным для управления (открываются/закрывают) соединение, и транзакция (запускаются/фиксируют/откатывают) все же. Почему?->, потому что Репозиторий не знает или понятие контекста, в котором это используется. Именно Ваш прикладной уровень или уровень служб (слой использует Вашу модель предметной области и следовательно Ваш репозиторий), который должен быть ответственен за открытие нового соединения и запуск / фиксация транзакций. (Или в Вашем случае, откройте новый DataContext). Вы могли затем передать DataContext репозиторию.
(У Eric Evans есть замечательная книга относительно DDD, хотя трудная задача, время от времени).
Необходимо быть осторожными с терминологией. Когда Вы говорите, что LINQ, Вы имеете в виду Linq-to-sql и когда Вы говорите 3-уровневый, который обычно означает Вас, говорят о сценарии развертывания с 3 отдельными машинами. Я не уверен если, именно это Вы имеете в виду.
Архитектура с тремя слоями является все еще хорошей идеей при использовании инструмента ORM как linq-to-sql. DAL становится просто местом для хранения логики запроса. Это - хорошая идея вынуть Ваши запросы из Вашего бизнес-слоя, потому что запросы являются беспокойством персистентности, не беспокойством бизнес-логики.
Обычная техника для управления контекстом данных состоит в том, чтобы иметь единственный контекст данных на запрос.
С точки зрения других статей о предмете можно посмотреть на любое руководство архитектуры любым инструментом ORM - linq-to-sql, не отличается. Ищите статьи об архитектуре для NHibernate.
LINQ к библиотеке SQL является Ваш DAL в этом случае, и вместо того, чтобы делать традиционные вызовы API из Вашего бизнес-слоя (например, DAL.GetObjectById (идентификатор)), у Вас есть гибкость намного более выразительных запросов в DAL.
Если бы у Вас были некоторые другие потребности, например, Ваш собственный поставщик LINQ, который соединяется с non-MSSQL поддержкой данных, то Вы реализовали бы свой собственный DAL.
Дополнительно относительно DataContext, не рекомендуется использовать шаблон "одиночка" с "одним резидентным DataContext". Объект DataContext должен представить единственную логическую транзакцию, независимо от того, что это означает для Вашего приложения. (Перефразируемый из http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopefully-a-realistic-world.aspx)