Где разместить дополнительную функциональность для уровня базы данных (Linq-to-SQL)

#.net #linq #linq-to-sql #design-patterns

Вопрос:

Каков был бы наилучший метод реализации дополнительных функций на уровне базы данных, использующем Linq-to-SQL? В настоящее время я рассматриваю возможность реализации функций для добавления информации на основе предустановок и аналогичных задач?

Для вставки, обновления и удаления требуется доступ к DataContext классам и в Table классах, у которых нет доступа к контексту. Я видел решения, в которых используются синглеты, но это похоже на взлом, и мне интересно, сталкивался ли кто-нибудь еще с этой проблемой и каковы были ваши решения? Есть ли лучший способ все вместе реализовать аналогичную функциональность.

Причина, по которой я хочу добавить эту функциональность на уровень базы данных, заключается в том, что у меня есть несколько приложений, которые используют одни и те же объекты базы данных, и я хочу иметь возможность использовать эти функции из всех приложений, чтобы мне не приходилось переписывать много кода.


Это не совсем то, что я имел в виду. Я хочу иметь возможность выполнять сложные действия, такие как обновление одной таблицы и добавление записи в другую таблицу на основе информации из первой.

Допустим, я выбрал запись о клиенте и хочу обновить ее информацией, и когда это произойдет, я хочу, чтобы она добавила еще одну запись в таблицу «Обновления», чтобы отслеживать, когда произошли обновления и кто их сделал. Это, конечно, только пример. Вещи, которые необходимо сделать, могут быть более сложными.

В принципе, я хочу добавить метод к объекту таблицы, чтобы выполнить изменения в определенной строке в этой таблице, а затем выполнить вставки и обновления для других объектов. Я знаю, что вы можете использовать частичные классы, и я уже широко это делаю.

Пример:

 db.Customers.Where(c => c.CustomerID == 5).AddOrder(orderDetails);
 

Я чувствую, что на самом деле не могу выразить свою проблему словами, чтобы сделать ее понятной 🙂

Ответ №1:

Классы сущностей в Linq to SQL являются частичными. Вы могли бы расширить их с помощью необходимых вам правил.

Или вы можете создать свои собственные бизнес-объекты из объектов Linq в SQL. Затем ваши бизнес-структуры будут содержать правила о том, когда и что делать.

Ответ №2:

Если вы просто добавляете некоторые функции оболочки вокруг linq или любого класса в целом, не могли бы вы использовать подход метода расширения в C# 3 и выше, используя статические вспомогательные методы в этом направлении:

 public static class StringExtensions 
{
    public static int ToInt(this string oString)
    {
        return int.Parse(oString);
    }
}
 

Таким образом, у вас может быть статический вспомогательный класс, предлагающий вспомогательные функции, специфичные для конкретных классов, которые вы можете переносить между проектами или, возможно, вставлять в отдельную библиотеку DLL и просто импортировать там, где это необходимо?

Ответ №3:

Мне неприятно это говорить, но как насчет хранимых процедур?

В моем проекте, какую бы дополнительную функциональность мы ни хотели предоставить, мы придерживаемся частичного класса. Класс контекста данных помечен как частичный, поэтому вы можете добавлять методы в контекст, не беспокоясь о повторном создании контекста, разрушающего вашу работу.

Ответ №4:

Вы можете использовать общие расширения контекста данных для общих методов доступа к данным,таких как вставка, удаление и т.д., Как описано в http://weblogs.asp.net/stephenwalther/archive/2008/08/26/asp-net-mvc-tip-38-simplify-linq-to-sql-with-extension-methods.aspx. и частичные классы для менее распространенных функций, как предложил Уилл.