Как Вы абстрагируете свой код персистентности при использовании LINQ для SQL?
Это связано с мягким и жестким механизмом в Nagios.
Например, если ваша служба esgg настроила max_check_attempts 3 в своем определении службы, вы увидите что-то вроде этого:
[1549377065] SERVICE ALERT: esgg;HTTP;CRITICAL;SOFT;1;CRITICAL - Socket timeout
[1549377195] SERVICE ALERT: esgg;HTTP;CRITICAL;SOFT;2;CRITICAL - Socket timeout
[1549377265] SERVICE ALERT: esgg;HTTP;CRITICAL;HARD;3;CRITICAL - Socket timeout
Вам нужно 3 плохих непрерывных проверки, чтобы получить состояние HARD и уведомление. [116 ]
4 ответа
Для себя; Я доволен повторным использованием объектной модели, которую генерирует LINQ / dbml, поскольку на самом деле атрибуты мне не вредят, и любая другая реализация может предоставить достаточно похожую модель, но я не использую свой контекст данных за пределами DAL. Итак, у меня есть что-то вроде:
IFooRepository- определяет доступные методы, используя как сгенерированные объекты dbml, так и некоторые классы модели POCOFooRepository- реализация, которая знает о контексте данных
My методы репозитория не раскрывают такие концепции LINQ, как IQueryable и Expression <...> , поскольку они являются дырявыми абстракциями ; другие реализации будут работать иначе (например, EF поддерживает разные аспекты обоих).
Далее - I ' я стал отмечать большинство свойств ассоциации как внутренние и использовать их только во время запросов DAL (не так много во время объектно-ориентированной работы).
Я мог бы сопоставить их с чистыми POCO, но я не вижу пользы. У меня есть еще несколько мыслей по этому поводу: Pragmatic LINQ .
Вы можете использовать аналогичный подход, подобный тому, который использовался в NerdsDinner . Этот проект использует этот контекст в качестве шлюза к базе данных и строит вокруг него репозиторий.
Этот вид шаблона репозитория добавляет некоторые условия, фильтры, команду сортировки и т. Д. В соответствии с вызываемым методом, а затем возвращает IQuerable вызывающему, оставляя дверь открытой для дальнейших изменений.
На самом деле вы делаете почти то же самое при создании репозитория на основе NHibernate ISession.
Если вы, например, решили заменить LinqtoSql на NHibernate, вам нужно просто запросить сеанс Linq внутри вашего репозитория, а не из контекста данных. Конечно, вам нужно будет дополнить ваши частичные классы свойствами, которые LinqtoSql добавляет автоматически.
Привет, Натан, хороший вопрос.
Как говорили другие, лучше всего абстрагироваться от всех ваших методов GET / WRITE и полностью скрыть DataContext от вашей бизнес-логики.
Мой подход к этому заключался в том, чтобы написать DAL с набором универсальных методов, которые используют отражение, чтобы делать все, что необходимо.
В этих случаях, как только метод получает объект, скажем «Продукт», он может делать все, что он хочет, независимо от вашей технологии ORM / доступа к данным. Если вы хотите, он может буквально просто написать строку SQL на основе нескольких параметров и отражения объекта.
ОДНАКО , выполнение этого само по себе не приведет к полному отключению вас от LINQ to SQL.
Проблема действительно в самих сущностях. Даже если вы абстрагируете метод получения данных, вы
Mouk выше упоминает шаблон репозитория в NerdsDinner, здесь также есть руководство по его быстрой настройке:
http://www.asp.net/learn/mvc/ tutorial-10-cs.aspx
Это небольшая хорошая серия руководств, выпущенных до NerdsDinner. Эту концепцию можно также настроить в традиционном приложении веб-форм asp.net.
Кроме того, я бы предложил вместо этого использовать Linq To Entities (более новые и более поддерживаемые для других БД), некоторые основы по этому поводу приведены здесь: http://www.asp.net/learn/mvc/tutorial-16-cs.aspx