Вопрос дизайна класса datacontext Linq-to-sq?

Question

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

Учитывая, что фон, я смотрел продлил некоторые из моих LINQ-к-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 птицы одним камнем.

Answer 1

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

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