2010-06-21 5 views
1

웹 시나리오에서만 linq-to-sql을 사용하고 있습니다. 항상 datacontext를 사용하여 포장하는 것이 좋지만 웹 시나리오에서만, 제가 설계하고있는 시나리오의 종류입니다. 각 페이지가 생성되어 매우 짧은 시간 안에 죽을 것이기 때문에 실제로는 필요하지 않습니다. 그 배경을 감안할 때 Linq-to-SQL datacontext 클래스 디자인 질문?

는, 내가 검토 한 같은

그래서
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() 

로 내 LINQ - 투 - SQL 클래스의 일부는, 이것이 내가 고용 한 설계 구조이며가 잘 작동하도록 나타납니다 확장 내 경우. 내 문제의 일부는이 기본 제공 멤버십 구조를 사용하고 있으며 내 자신을 쉽게 다시 작성하지만 특정 제한 사항이있는 추가하려고하는 것입니다. 물론, 개체에 대한 인터페이스의 정확한 구성은 이상적이지 않습니다. 일부 기능이 데이터베이스 테이블 전반에 걸쳐 계층화 되었기 때문입니다 (좋든 나쁘 든).

제 질문은 aspnet_Membership과 같은 일부 자식 개체의 경우 자체 DC로 확장했습니다. 그러나 수동으로 설정하지 않고 모든 어린이 DC를 업데이트하는 메커니즘은 아직 없습니다.

다소 우아한 방식으로이 문제를 해결할 수있는 최소한의 코딩이 필요한 다양한 디자인 솔루션을보고 싶습니다.

또한 개체의 계층화에 대한 세부적이고 구체적인 제안을 환영 할 것입니다. 한 돌로 죽이는 새 2 마리가 될 수 있습니다.

답변

0

실제로는 System.Web.Security.MembershipProvider 클래스가 제공하는 메소드를 통해 멤버십을 조작해야합니다. ASP.NET Membership 데이터베이스에서 데이터베이스 테이블을 직접 조작하는 것은 좋지 않습니다.

System.Web.Security.MembershipProvider을 사용자 정의 클래스로 랩하려면 다음을 수행하십시오. 실제로 ASP.NET MVC는 단위 테스트를 더 쉽게 수행 할 수 있도록 정확하게 수행합니다. 하지만 실제로는 DataContext가 아닙니다.

+0

네, 저도 그렇게했는데 linq-to-SQL 기능을 사용하는 것이 일부 작업, 특히 쿼리에 편리 할 것이라고 결정했습니다. DRY 원칙에 따라 기본 linq-to-sql 클래스를 사용하는 대신 결과에 대한 클래스를 생성하기로 결정했습니다. 자, 나는 그것에 대해 생각한다. 나는 DC가 해결 될 수있는 좀 더 일반화 된 문제이기 때문에 이것을 떠날 것이다. –