Linq-to-sql datacontext дизайн класса вопрос? - PullRequest
1 голос
/ 22 июня 2010

Я использую linq-to-sql только в веб-сценарии.Я знаю, что рекомендуется всегда оборачивать текстовый текст при использовании, но только в веб-сценарии, для сценария, для которого я разрабатываю, это действительно не нужно, потому что каждая страница будет появляться и умирать за очень короткое время.

Учитывая этот фон, я рассмотрел расширенные некоторые из моих классов linq-to-sql как таковые

public partial class aspnet_User
{
    MainDataContext _dc = new MainDataContext();

    public MainDataContext DataContext 
    {
        get
        {
            return _dc;
        }
        set
        {
            _dc = value;
        }
    }

        public static aspnet_User GetUser(Guid guid)
        {
        //Here I load the user and associated child tables. 
        //I set the datacontext for the aspnet_User with the local DC here
        }

       //_dc.SubmitChanges()
       public SaveUser()

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

У меня вопрос к некоторым дочерним объектам, таким как aspnet_MembershipЯ также расширил это своим собственным DC.Но у меня пока нет механизма для обновления всех детских DC без установки каждого вручную.

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

Кроме того, любые подробные и конкретные предложения о расслоении объектов могут быть оценены.Это может быть убить 2 птицы одним камнем.

1 Ответ

0 голосов
/ 22 июня 2010

Вы действительно должны манипулировать Членством с помощью методов, изначально предоставленных классами System.Web.Security.MembershipProvider. Не рекомендуется манипулировать таблицами базы данных в базе данных членства ASP.NET напрямую.

Если вы хотите обернуть System.Web.Security.MembershipProvider в свой собственный класс, это нормально; фактически ASP.NET MVC делает именно это, чтобы упростить выполнение модульного тестирования. Но это не совсем DataContext, как таковой.

...