2009-03-25 3 views
2

현재 WebForms의 일부 개인 웹 사이트를 MVC로 변환하는 중입니다. 기존 사이트에서는 데이터베이스 스키마가 견고하지만 적절한 데이터/비즈니스 모델/계층을 구축 할 시간이 없었습니다. aspx 페이지는 모두 편의상 필요에 따라 만들어진 다양한보기 및 저장 프로 시저를 사용하여 데이터베이스와 직접 대화했습니다. MVC를 사용하여 LINQ to SQL 및/또는 Entity Framework와 같은 기술을 사용하여 응용 프로그램에 적합한 데이터 모델을 작성하는 것처럼 "올바르게 수행"하려고합니다.ASP.NET MVC의 모델 설계 조언

내 질문은 데이터 모델을 구축 할 때 취해야 할 목표를 중심으로 이루어졌습니다. 다양한 패턴 관련 기사를 읽었으며 궁극적으로 그 대답이 내 데이터의 특성에 달려 있음을 알고 있습니다. 그러나 일반적으로 가능한 한 많은 데이터베이스를 포함하는 더 큰 모델을 만들어서 주어진 테이블 세트와 상호 작용할 수있는 유일한 방법이 있어야합니까? 또는 뷰에서 필요로하는 데이터와 액세스 만 포함하는 각 MVC 뷰에 대해 더 작은 사용자 정의 모델을 작성해야합니까?

+0

정말로 흥미로운 질문입니다. +1 – User

답변

2

또는보기에 필요한 데이터와 액세스 만 포함하는 각 MVC보기에 대해 더 작은 사용자 지정 모델을 만들어야합니까?

아마도 더 좋을 것입니다.

모델을 계층 구조로 고정 할 수 있으므로 ID, 이름, 환경 설정과 같은 공통 속성이 각 모델에 존재할 수 있습니다.

뚱뚱한 확장 된 모델은 프레임 워크가 자동으로 미리로드 된 사용자 환경 설정, 사용자 역할, 액세스 권한 등을 기반으로 많은 것들을 수행하는 엔터프라이즈 응용 프로그램에 더 좋을 수 있습니다. 작은 개인 프로젝트의 경우 모델을 작게 유지하는 것이 좋습니다 깨끗하게. 또한 보호 장치이기도합니다. 불필요한 데이터를 모델에 저장하지 않으면 실수로 잘못된 항목을 표시하거나 양식을 제출하지 않아도 실수로 다른 데이터를 덮어 쓰지 않습니다.

+0

이것이 제가 합의한 해결책이기 때문에 이것이 합의로 보이는 것에 기쁩니다. 더 많은 클래스가 더 복잡하고 유지 보수가 덜하다는 단정 한 의심이있었습니다. –

0

내가 현재의 시스템 내에서 실제 데이터 로직을 대표하는 모델에 가서 컨트롤러가보기와 같은 필요한 모델의 조각을 반환 할 것이다 :

컨트롤러 :

public ActionResult index() 
{ 
    var ListOfObjects = DataHelper.GetAll(); 
    ViewData.Add(ListOfObjects); 
    return View(); 
} 

public ActionResult ViewObject(int id) 
{ 
    var Object= DataHelper.GetObject(); 
    ViewData.Add(Object); 
    return View(); 
} 

public ActionResult ViewObjectChild(int Objectid, int ChildId) 
{ 
    var Child= DataHelper.GetChildObject(Objectid, ChildId); 
    ViewData.Add(Child); 
    return View(); 
} 

에를 뷰

/

<% var myListOfObjects = ViewData.Get<IList<Object>>(); %> 

내가 MVC있는 contrib를 사용하고/ViewObject/1/

<% var myobject= ViewData.Get<Object>(); %> 

/ViewChild/1/1/

<% var myChild = ViewData.Get<Child>(); %> 

참고 내가보기 엔이 추천 기능을 입력했습니다.

0

일반적으로 데이터베이스에 대한 포괄적 인 도메인 모델이 있습니다. 작은 응용 프로그램 인 경우 서비스 계층이나 컨트롤러에서 도메인 모델을 (수정/추가/제거/등) 사용할 수 있습니다.

그러나보기에 대해 프레젠테이션 개체를 사용하면보기를보다 쉽게 ​​유지 관리 할 수 ​​있습니다. 이들은 때때로 DTO 또는 뷰 모델 객체라고도합니다. 기본적으로 뷰에서 채워지는 데 필요한 모델의 모든 데이터가 포함 된 개체를 만듭니다.

예를 들어

:

귀하의 모델이 포함될 수 있습니다

public class Car() 
{ 
    public string Model; 
} 

public class Driver() 
{ 
    public string Name; 
} 

당신은 출력에보기에게 이름과 자동차의 모델을 원하는 당신은 차를 모두 통과해야 및 드라이버 모델은 객체 전망. 당신은 도메인 데이터 패스에서이 개체를 채우는 것

public class CarAndDriverViewModel() 
{ 
    public string CarMake; 
    public string DriverName; 
} 

:

오히려 두 모델을 보내는 뷰에 컨트롤러에서 직접 객체보다, 당신은 당신이 필요로하는 데이터 만 포함 된 개체를 만들 수 있습니다 저것은 전망에. 그리고보기는 다음과 같습니다

model.DriverName + ": " + model.CarMake 

지금 당신이 모델의 특수성을 다루는 게으른 로딩 문제 나 복잡한 뷰 로직에 대해 걱정할 필요가 없습니다. 이러한 뷰 모델 객체를 만드는 것이 더 많은 작업이지만 뷰를 깨끗하게 유지하는 데 도움이되며 뷰에 데이터를 보내기 전에 서식을 쉽게 지정할 수 있습니다.

보기 모델의 생성을 자동화하기 위해 사용할 수있는 프로젝트와 규칙이 있습니다. AutoMapper이 그 예입니다.