Entity Framework없이 MVC에 데이터 저장?

asp.net asp.net-mvc c# dapper

문제

내가 본 MVC 예제의 대부분은 Entity Framework를 사용하는 것 같습니다. 저는 현재 Dapper를 대신 사용하는 EF를 사용하지 않는 MVC 응용 프로그램을 작성하고 있으며 데이터 지속성 논리를 어디에 포함해야하는지 궁금합니다.

나의 첫 번째 생각은 그것을 내 모델의 수업과 함께 배치하는 것이었다. 이것은 내 모델 클래스가 다음과 같을 것임을 의미합니다.

class User
{
   public int id {get; set;}
   public string name {get; set;}

   Create(string name)
   {
      // dapper to perform insert
   }

   Remove(int id)
   {
     // dapper to perform delete
   }

   //Update(),Delete() etc.
}

하지만 MVC를 많이 사용하지 않아서 이것이 일반적인 관행인지 아닌지 확실하지 않습니다.

모델에 데이터 지속성 로직을 배치하는 것이 좋은 방법인가 아니면 다른 접근 방식을 취해야합니까?

또한, 스택 익스체인지는 MVC와 Dapper를 사용한다고 생각합니다. 코드를 구조화하는 방법에 대해 누구나 알고있는 사람이라면 언제든지 나를 향해 가리킬 수 있습니다.

수락 된 답변

컴퓨터를 열고 하드 드라이브의 버튼을 눌러 데이터를 저장해야 할 필요는 없을 것입니다.

기본적으로 MVC 패턴의 목적과 일반적으로 SOLID 설계 원칙은 사용자의 관심사를 분리하는 것입니다. 데이터를 포함하는 객체가 될 책임이있는 모델 내부에서 데이터베이스를 저장, 수정 또는 업데이트하는 것과 관련된 논리를 설정하는 것은 MVC에서 가입해야하는 패턴 철학에 위배됩니다.

컨트롤러는 정보를 저장하는 논리 를 수행하려는 곳이지만 데이터베이스와의 상호 작용에 대한 관심이 추상화 된 데이터 액세스 계층은 여전히 ​​존재합니다.

그래서 당신은 :

public class MyController {
    IDataAccessLayer _dataAccessLayer;

    public MyController(IDataAccessLayer dataAccessLayer) {
        _dataAccessLayer = dataAccessLayer;
    }
    public ActionResult Create(Model myModel){
        _dataAccessLayer.InsertIntoDatabase(myModel);
        return View();
    }
}

인기 답변

MVC 지속성의 디자인마다 결코 문제가되지 않습니다. 원하는 ORM을 사용할 수 있습니다. MVC 패턴이 작동하려면 뷰에 데이터를 표시하기 위해 Model (부분 뷰 모델)이 필요합니다. 컨트롤러가 응용 프로그램의 흐름을 처리합니다.

이제 컨트롤러에서 모든 프로세스를 호출하여 데이터를 저장할 수 있습니다.

나는 EF와 마찬가지로 Dapper와 Repository 패턴을 사용할 수 있다고 생각합니다.

응용 프로그램이 지속성을 인식하지 않도록주의해야합니다. Dapper를 사용하여 개발할 수 있으며 나중에 UI 수준을 크게 변경하지 않고도 EF를 지원할 수 있습니다.



아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
이 KB는 합법적입니까? 예, 이유를 알아보십시오.
아래 라이선스: CC-BY-SA with attribution
와 제휴하지 않음 Stack Overflow
이 KB는 합법적입니까? 예, 이유를 알아보십시오.