문제

나는 Pro ASP Net MVC 프레임 워크를 읽고 있었고 많은 것들과 혼란스러워하고 있습니다. 나는 약간의 연구를하려고 노력했지만 많은 다른 접근법과 개념이 나에게 던져지면서 상황이 악화되고 있다는 것을 알게되었습니다.
그래서 몇 가지 질문이 있습니다.

  1. MVC가 기능을 모델 -> 컨트롤러 ->보기의 세 가지 주요 사항으로 나누어야한다는 것을 알고 있습니다. MVC는 3 계층 아키텍처와 다른 접근 방식입니까? 아니면 여전히 내 프로젝트에서 데이터 액세스 계층과 비즈니스 로직 계층을 만들려는 생각이 있습니까?

  2. 저장소는 정확히 무엇입니까? 내 데이터 액세스 계층 역할을하는 것은 무엇입니까? 리포지토리는 MVC에 어디서 적합합니까?

  3. 이 책은 LINQ에서 SQL을 사용하여 데이터베이스와 상호 작용하는 것에 대해 이야기하지만 LINQ에서 SQL에서 SQL에서 SQL이 지원되지 않으며 Microsoft는 엔터티 프레임 워크를 위해이를 삭제하고 있다고 말합니다. 엔티티 프레임 워크는 MVC에 어디에 적합하며 어떻게 상호 작용합니까?

도와 주셔서 미리 감사드립니다!
매트

도움이 되었습니까?

해결책

  1. MVC는 주로 프리젠 테이션 계층의 패턴이며 뷰와 컨트롤러 간의 상호 작용에 중점을 둡니다. 모델은 고려 될 수 있습니다 상태를 유지 관리하는 응용 프로그램의 구성 요소, 지속성을 포함하여.

    간단한 응용 프로그램에서 모델은 LINQ-to-SQL 모델 일 수 있습니다. 대규모 엔터프라이즈 애플리케이션에서 모델에는 데이터 액세스 계층, 비즈니스 계층 및 도메인 계층이 포함될 수 있습니다. ASP.NET MVC는 M을 구현하는 방법으로 귀하를 제한하지 않습니다.

  2. 그만큼 저장소 패턴은 M의 지속성 부분을 구현하는 한 가지 방법입니다. activerecord 또 다른 것입니다. 선택할 패턴은 응용 프로그램의 복잡성과 선호도에 따라 다릅니다.

    보세요 3 단계 LINQ에서 SQL을 사용하여 간단한 저장소를 생성하는 Nerddinner 튜토리얼의.

  3. LINQ에서 SQL은 죽지 않습니다. Microsoft는 여전히 핵심을 개선하고 의미가있는 곳에 고객 요청을 추가하지만 엔티티 프레임 워크가 주요 초점이 될 것입니다. 이 게시물을 살펴보십시오 .NET 4.0에서 LINQ에서 SQL이 변경됩니다.

    EF는 LINQ에서 SQL과 유사한 방식이지만 다른 방식으로 사용할 수 있으므로 더 유연합니다. 예를 들어 EF4는 도메인 구동 설계에서 자신의 POCO 객체의 지속성을 어느 정도 지원합니다.

다른 팁

그렇습니다. MVC는 "여기에서 의미하는"3 계층 아키텍처 (주로 3 개의 프로젝트 Dal, BL 및 UI를 만드는 아키텍처)와는 다른 접근법이라고 생각합니다. MVC의 주요 아이디어는 각 구성 요소 (모델, 뷰 및 컨트롤러) 간의 문제를 분리하는 것입니다. 컨트롤러는 사용자 요청을 처리하는 구성 요소이며 대부분의 경우 사용자 요청에 대한 응답으로 원하는보기를 표시하기 위해 "모델"구성 요소가있는 회사입니다. 이것과 전통적인 3 계층 아키텍처의 차이점은 Dal과 BL이 현재 그룹화되어 모델로 명명된다는 것입니다. 예, 여전히 이러한 구성 요소를 만들어야합니다.
저장소 란 무엇입니까?
마틴 파울러 저장소의 정의를 언급합니다 "도메인 객체에 액세스하기 위해 컬렉션과 같은 인터페이스를 사용하여 도메인과 데이터 매핑 계층 간의 중재" 리포지토리는 데이터 액세스 계층의 일부이며 데이터 자체에 액세스하지 않으며 도메인과 데이터 매핑 엔티티 사이를 중재하며 물론 모델 폴더/프로젝트에 배치해야합니다.

LINQ에서 SQL을 사용하지 않습니까?
아니 그리고 같은 책은 SO, Damien Guard (ADO.NET 팀의 개발자)도 블로그 게시물 중 하나에서 LINQ에서 SQL이 .NET 4.0에 포함될 것이라고 언급했습니다.

EF와 상호 작용하는 방법?
LINQ에서 SQL과 마찬가지로. LINQ에서 SQL과 마찬가지로 엔티티 프레임 워크가 매핑 엔티티가되며 모델 프로젝트에도 상주 할 것입니다.
도움이 되었기를 바랍니다!

나는 당신이 이런 것들에 대해 약간 혼란스러워하는 것 같아요. ~이다 혼란스러워서 천천히 가자.

  1. n 계층 아키텍처와 MVC는 다르지만 얽혀 있습니다. N-Tier는 일반적으로 데이터 액세스, 비즈니스 로직 및 사용자 인터페이스 분리에 대해 이야기합니다. 그러나 일부 사람들은 UI에서 BLL을 완전히 분리하는 것이 불가능하다고 주장 할 수 있습니다. MVC는 귀하의 견해가 BLL과 직접 대화하는 것과는 대조적으로 해당 컨트롤러가 귀하의 BLL과 대화하고 귀하의 관점에 대해 이야기하는 방식으로 처리합니다.

  2. 예, 리포지토리를 갖는 것은 DAL을 갖는 한 가지 방법입니다.. 이 작업을 수행하는 방법에는 여러 가지가 있으며 책에서 논의 된 내용으로 자신을 제한해서는 안됩니다.

  3. 이 책은 LINQ에서 SQL 만 사용하여 ASP.NET MVC를 가능한 가장 빠른 방법으로 시연하지만 유일한 방법은 아닙니다. LINQ에서 1 분 동안 SQL에 대한 생각을 중단하십시오. ASP.NET MVC는 nhibernate와 같은 ORM을 사용하든 일반 ado.net + dal factory 또는 무엇이든 사용하든 사용할 수 있습니다. 사용할 수 없을 것입니다. ASP.NET입니다. ObjectDataSources 당신이 당신의 UI로 드래그하고 떨어 뜨린다.

Entity Framework의 경우 Brad Abrams는 멋진 가이드를 썼습니다. ASP.NET MVC와 함께 엔티티 프레임 워크 사용 방법, 그것은 당신의 마지막 질문을 다루어야합니다.

HTH

  1. 예, 여전히 데이터 액세스 및 비즈니스 로직 계층을 직접 만들어야합니다. 일부는 컨트롤러 계층이라고 주장 할 수 있습니다 이다 비즈니스 로직이지만 개인적으로 스크린 비즈니스 로직 (예 : "OK"버튼의 이벤트 핸들러)에서 실제 비즈니스 로직 (예 : 가격 계산) 간의 분리를 선호합니다. 그런 다음 컨트롤러 클래스에서이를 호출합니다. 컨트롤러 클래스는 화면의 논리를 제어하고 데이터/비즈니스 로직 계층에서 화면 값으로 변환을 관리합니다.

  2. ASP.NET MVC 프레임 워크는 "모델"레이어에 제한이 없으므로 NHibernate, LINQ에서 SQL 또는 엔티티 프레임 워크를 포함하여 원하는 것을 사용할 수 있습니다. 간단하기 때문에 LINQ에서 SQL을 사용합니다.

  3. 확실하지 않습니다. 그 책을 읽지 마십시오. 방금 CodePlex에서 Scott Hanselman의 Nerddinner 프로젝트를 다운로드하여 ASP.NET MVC 웹 사이트를 작성하기위한 가이드로 사용했습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top