jQuery 대화 상자 내 양식에 대해 MVC에서 일반적으로 허용되는 접근 방식

jQuery 대화 상자 내 양식에 대해 MVC에서 일반적으로 허용되는 접근 방식

jQuery 대화상자를 ASP와 통합하는 방법은 여러 가지가 있는 것 같습니다.NET MVC. 특정 접근 방식이 일반적으로 인정되는 모범 사례 방법으로 등장했습니까?

예를 들어,나열된 항목 중 하나에 대해 "편집"을 클릭하면 항목의 세부 정보가 채워진 jQuery 대화 상자의 양식이 열립니다.사용자가 세부 정보를 편집하고 "저장"을 클릭합니다.서버 측에서 저장이 성공하면 대화상자가 닫히고 목록이 새 데이터로 다시 작성됩니다.서버 측에서 저장이 실패할 경우, 대화상자는 열린 상태로 유지되고 사용자에게 오류 메시지를 표시합니다.

1. No-JSON 접근법: 각 "편집" 링크는 "편집" 컨트롤러 작업에 대한 HREF입니다.이 컨트롤러 작업은 "목록" 보기와 동일한 보기를 작성하며 편집 양식을 작성하고, 채우고, jquery 대화상자로 열기 위해 Javascript를 정의하는 부분 작업을 포함합니다.저장은 양식 게시물입니다. 저장이 성공하면 리디렉션 작업을 목록 페이지로 다시 반환합니다.실패하면 오류 메시지를 표시하는 전체 페이지(대화 상자에 나타나는 양식 포함)가 다시 작성됩니다.
2. All-JSON 접근 방식: 목록 페이지는 빈 편집 양식(숨김)을 렌더링하여 대화 상자에 팝업으로 열 수 있습니다."edit" 링크는 전체 객체를 가져오기 위해 Ajax 요청을 수행하는 로컬 Javascript를 호출합니다(나는 전체 객체를 JsonResult로 반환하는 컨트롤러를 정의합니다).성공하면 편집 양식을 개체의 데이터로 채우고 대화 상자를 엽니다."save" 링크는 폼 데이터를 json 개체로 묶는 로컬 javascript를 호출하고, 해당 json 개체를 페이로드로 사용하는 사후 작업을 호출합니다(나는 해당 개체를 예상하고 저장을 시도하고, 성공/실패+errorMessages를 나타내는 jsonResult를 반환하는 컨트롤러를 정의합니다).Ajax 요청의 성공 콜백은 반환된 개체를 평가하고 여전히 열려 있는 jquery 대화 상자에 오류 메시지를 표시하거나 대화 상자를 닫고 "list" 페이지를 다시 로드하여 목록에 새 데이터를 가져옵니다.
3. [편집] Ajax-HTML 접근법: 방금 다른 접근법을 설명하는 SO 토론을 보았습니다."편집"은 대화상자의 전체 HTML을 가져오기 위해 아약스 게시물을 하는 로컬 자바스크립트를 호출합니다(나는 부분 보기를 반환하는 컨트롤러를 작성할 것입니다: 전체 입력 양식).반환된 HTML을 jquery 대화상자로 렌더링하고 양식 내용의 Ajax-post를 수행하기 위해 양식 제출을 "재배선"합니다(위의 #2에서와 같이 httpPost 컨트롤러를 작성합니다).성공 콜백은 응답을 평가하고 오류 메시지를 채우거나 대화 상자를 닫습니다.
4. 내가 생각해보지 못한 멋진 접근법?

옵션 1은 "순수한" ASP와 더 일치하는 것으로 보입니다.NET MVC.그러나 모든 요청에 대해 전체 페이지를 브라우저로 다시 전송하기 때문에 HTTP 페이로드가 크고, 모든 요청에 대해 목록을 재구성하기 때문에 서버 측 성능이 느립니다.

옵션 2는 보다 현대적인 Ajax 기반 웹 애플리케이션(작은 HTTP 페이로드, 보다 세분화된 작업)과 더 일치하는 것으로 보입니다.그러나 많은 컨트롤러가 JSON 컨트롤러가 될 것으로 보이며, JSON 객체에서 폼 필드로 데이터를 이동하거나 오류 메시지를 표시하기 위해 클라이언트 측 코드를 많이 작성할 것입니다.EditorFor() 및 ValidationMessageFor()와 같은 멋진 MVC 기능도 많이 놓칠 것 같습니다.MVC 시스템을 사용하는 대신 MVC 시스템을 사용하는 것처럼 "느낄" 뿐입니다.

[편집: 옵션 3 추가] 옵션 3은 1과 2의 하이브리드가 조금 된 것 같습니다.저는 "순수한" MVC 접근 방식을 사용하여 양식을 작성하고 채우고 완전한 형식의 HTML FORM 태그를 반환합니다.HTML을 아약스 요청으로 되돌리는 것은 너무 장황해서 이상하게 느껴지지만, 저는 극복할 수 있습니다.사후 작업은 아약스보다 "느낌이" 좋은 컴팩트한 JSON입니다.그러나 payload 객체가 실제 뷰 모델 객체가 아닌 FormCollection 객체인 것은 유감입니다.일부 MVC 편의성(EditorFor())은 활용할 수 있지만 다른 편의성(ValidationMessageFor())은 활용할 수 없는 것 같습니다.

저는 이것을 함께 해킹하는 가장 빠른 방법이 아니라 "올바른" 방법을 찾고 있습니다.네, 네, 보편적으로 "올바른" 방법이 없다는 것을 압니다.하지만 분명히 잘못된 방법들이 있을 것입니다. 그리고 저는 그것들을 피하고 싶습니다.

저는 ASP에 꽤 경험이 있습니다.NET/C#입니다만, MVC는 처음입니다.도움을 주셔서 미리 감사드립니다!

[편집] - 뛰어난 답변 - 여러 답변이 매우 유용하다는 것을 알았기 때문에 여러 답변/바운티를 수여할 수 있으면 좋겠습니다.하지만 저는 할 수 없기 때문에, 저는 1위를 한 응답을 답으로 표시하고 있습니다.모든 응답자들에게 다시 한번 감사드립니다!

저희 팀과 저는 AJAX 지원 MVC 앱을 작성한 경험이 많고 3가지 접근 방식을 모두 사용했습니다.

하지만, 제가 가장 좋아하는 것은 분명히 AJAX-HTML 접근법입니다. -- 사용:PartialView서버 측 유효성 검사 메시지 및 기타 논리를 포함할 수 있는 대화 상자의 내용을 렌더링합니다.

이 접근 방식의 가장 큰 이점은 우려 사항을 분리하는 것입니다. 사용자의 보기는 항상 HTML의 렌더링을 담당하며 JavaScript는 JSON을 렌더링하는 데 필요한 텍스트, 마크업 또는 "템플릿"을 포함할 필요가 없습니다.

큰에 모든 할 수 있다는 입니다: views, 또다을큰장은 HTML는데하모든훌륭한을 MVC기능사력 : 유의보기형한강것다입니있다는수용할른더렌링점 : 력강▁another한유의,,보기▁are▁that▁available▁allc▁rendering▁is▁the형.HtmlHelper,DisplayFor그리고.EditorFor 템릿플,DataAnnotations합니다. 이렇게 하면 일관성을 유지하기 쉽고 리팩터링에 적합합니다.

단 하나의 접근 방식을 고수할 필요는 없습니다.AJAX 호출에 "성공"과 같은 상태 업데이트와 같은 간단한 것만 필요할 때는 다음을 사용하는 것이 좋습니다.string또는JSON그 메시지를 전달하기 위해서요PartialViewsHTML이 필요할 때, 그리고 의사소통이 필요할 때 더 간단한 방법을 사용합니다.

두 번째 방법인 All-JSON 접근 방식은 녹아웃과 같은 MVC 및 MVVM 클라이언트 사이드 라이브러리에서 점점 더 보편화되고 있는 것 같습니다.

이를 통해 JSON의 모든 데이터(목록 포함)와 편집 목록 항목(목록 항목 편집기 데모와 유사하며 대화 상자 렌더링이 인라인이 아닌 셀에서 읽기 전용 범위로 데이터를 바인딩)을 저장한 다음 전체 세트를 다시 서버에 직렬화할 수 있습니다.또는 각 팝업 편집 후 부분적으로 저장하여 수행할 수 있습니다.

JSFidle: http://jsfiddle.net/paultyng/weLtH/17/

JS를 좀 정리할 수도 있고, 저장 버튼을 포함하지 않았지만, 당신은 그 아이디어를 이해해야 합니다.편집 대화상자는 한 행당 수행하는 대신 하나의 편집에 바인딩된 단일 템플릿일 수도 있습니다. 이것은 녹아웃으로 수행하는 가장 간단한 방법입니다.

제 생각에 가장 좋은 방법은 목록을 정상적으로 렌더링하는 것입니다.편집 링크를 연결하여 일반적으로 하는 것처럼 별도의 페이지로 이동합니다(여기를 따라오세요).

JS를 사용하여 링크 클릭을 처리하고 href로 이동합니다.에▁▁check다니▁in▁a▁do합확인▁the▁actionRequest.IsAjaxRequest()표시된 경우 부분 보기를 반환하고, 그렇지 않은 경우 전체 보기를 반환합니다.또는 마스터 페이지 없이 일반 편집 보기를 렌더링합니다(보기() 호출 또는 호출 반환 부분()에서 마스터 페이지 매개변수에 null로 전달).결과의 내용을 가져와서 대화 상자에 넣습니다.

또한 JS를 사용하여 양식을 제출하고 요청에서 결과를 얻습니다.성공하지 못한 경우 대화상자에 보기 내용을 삽입하여 오류가 있음을 표시합니다.그렇지 않으면 닫고 다음으로 이동합니다.

이 접근 방식의 이점은 매우 눈에 띄지 않고 JS가 없는 사용자에게 여전히 기능을 제공한다는 것입니다.

좋아요, 당신의 옵션은 여기서 점진적인 향상의 개념을 거의 불태우고 있습니다. 만약 당신의 클라이언트가 자바 스크립트를 지원하지 않는다면 2와 3은 작동하지 않을 것입니다.당신이 신경쓰지 않아도 분명히 괜찮지만, 저는 그것들이 우아하게 퇴화되도록 일을 처리하려고 노력할 것이고 당신은 여기서 최선의 연습을 요구하고 있습니다.

그래서 제가 그것을 구성하는 방법은 당신의 옵션 1부터 시작합니다.편집 페이지를 로드하는 다른 작업을 트리거하는 편집 버튼이 있으며, 이 페이지는 일반적인 mvc에 따라 모든 검증자 등으로 설계되었습니다.기본 기능이기 때문에 J는 사용할 수 없습니다.

그러면 다음 질문은 어떻게 하면 새로운 페이지가 아닌 멋진 팝업을 가질 수 있도록 점진적으로 향상시킬 수 있을까 하는 것입니다.

첫 번째 단계는 클릭 시 편집 링크에 첨부된 대화 상자를 열 수 있는 핸들러를 만드는 것입니다(e).기본값 방지).이제 너무 많은 코딩 노력을 절약하기 위해 편집 페이지를 다시 사용하려고 합니다.Ajax 요청에 대한 레이아웃을 포함하지 않으려면 약간의 리팩터링이 필요합니다.이 작업은 몇 가지 방법으로 수행할 수 있지만 편집 보기의 편집 영역을 주 편집 보기가 모델을 렌더링하는 데 사용하는 부분 보기로 설정하는 것이 가장 깨끗하다고 생각합니다.

그런 다음 편집 작업에서 Ajax 요청이 있는지 확인하고, 있으면 PartialView(내 부분 편집 보기)를 반환하고, 없으면 View(편집 보기)를 반환할 수 있습니다.

편안한 삶을 원한다면 결과를 서버에 다시 제출하는 것과 관련하여, 그냥 양식처럼 다루면 됩니다.당신은 여기서 마이크로소프트 언서브 아약스를 사용할 수 있고 그것은 매우 간단할 것입니다.당신은 Ajax를 사용합니다.부분 보기에서 양식을 시작합니다. n.b.Ajax를 사용할 수 없는 경우 일반 형식으로 저하됩니다.이 시작 양식에 대한 AjaxOptions가 대화의 div를 업데이트하도록 설정하여 HTML로 응답하면 더 이상 아무것도 하지 않아도 됩니다. 그러면 유효성 검사 오류가 발생합니다.

[위에서 질문한 것처럼 작은 것은 제외하고:HttpPost 핸들러의 측면에서, 기본 모델 바인더는 놀라울 정도로 똑똑하며, 복잡한 클래스 객체 매개변수의 속성에 양식 필드를 바인딩할 수 있습니다.이는 json에서도 작동하므로 다양한 시나리오를 지원하기 위해 많은 작업 방법을 사용하지 않아도 됩니다.].

따라서 업데이트에 실패하면 포스트 핸들러가 부분 보기를 다시 반환하여 모델에 바인딩하므로 모든 검증자를 얻을 수 있습니다.그러나 업데이트가 성공적인 경우에는 아무것도 반환하지 않고 기본 페이지를 변경한 후 다시 로드하려는 기본 페이지로 리디렉션하는 것이 좋습니다.

만약 당신이 메인 페이지를 완전히 다시 로드하는 것을 좋아하지 않는다면, 그것은 당신이 html을 반환하는 위의 접근법과 같이 더 복잡해집니다.성공/실패를 나타내는 숨겨진 필드 또는 클래스를 찾거나 json 결과를 반환하는 순수 json 접근 방식으로 마이그레이션하려면 이를 쿼리해야 합니다.유지보수/코딩 전면에서 이 작업이 점점 더 무거워지고 있습니다.저는 아마 jquery check를 해서 그것을 ajax의 완료 핸들러에 연결시켜 놓았을 것입니다.양식을 시작합니다.

만약 여러분이 정말로 이 일을 잘 처리하고 싶다면, 저는 스티브 샌더슨 프로 Asp.net MVC 책이 매우 귀중하다는 것을 알게 되었습니다.처음에 읽은 것은 MVC2용이었지만, MVC3 업데이트를 읽는 중이었습니다.업데이트가 몇 군데에서 간소화되어 지금은 추적하기 쉽지만 몇 가지가 누락된 것처럼 느껴지며, 마지막에 가까워지면서 오류 등으로 인해 급하게 진행되었습니다.MVC4가 화제가 되고 책이 나오지 않아서 패닉에 빠진 것 같아요!그래도 여전히 좋은 책이고 이 모든 것을 아름답게 다룹니다.

이게 도움이 되길 바랍니다.위의 답변과 동일한 내용을 다루게 되어 감사합니다. 하지만 제가 당신을 위해 더 많은 것을 알려드릴 수 있기를 바랍니다.

용사를 합니다.jQuery.tmpl()플러그인¹

저는 비슷한 시나리오를 사용하지만 다른 방식으로 합니다.

각 있습니다.TR또는DIV). 목록에 할 수 일부 단순 목록에 포함할 수 없는 데이터가 너무 많은 경우 항목에 대한 일부 일반 정보가 마스터 목록에 표시됩니다.따라서 세부 정보가 아닌 마스터 목록입니다.

각 항목 컨테이너는 일반적으로 다음과 같이 작성됩니다.

<div class="item" data='<%= item.ToJson() %>'> <!-- single quotes! -->
    item visible list data
</div>

여기서 주요 부분은 사용자 지정 확장 방법입니다.ToJson()클라이언트에서 쉽게 사용할 수 있는 항목 데이터를 직렬화합니다.

그런 다음 목록의 끝에 jQuery 템플릿이 있습니다.script태그. 이 템플릿은 모든 항목 변수가 필요에 따라 설정된 편집 대화 상자의 실제 내용입니다.

사용자가 항목에서 편집을 클릭할 때마다 JSON 항목을 다음과 같이 구문 분석합니다.

// in edit link click handler
var itemData = $.parseJSON($(this).closest("[data]").attr("data"));
// display dialog
displayDialog($("#editDialog").tmpl(itemData));

나의 대화상자는 Ajax 통화를 통해 나머지를 처리하고 통화가 성공하거나 사용자가 편집을 취소할 때 대화상자를 닫습니다.

이렇게 하면 HTML 코드가 최소로 유지되고(템플릿이 하나만 있음) JSON에도 실제로 필요한 속성만 포함됩니다.

모델 클래스에 다른 도면요소 참조가 있는 경우 수행할 작업

개체가 서로 관련되어 있다는 것은 매우 일반적입니다.당신이 가지고 있다고 가정합니다.Post그리고.Comment도면요소:

public class Post
{
    public int Id { get; set; }

    public string Body { get; set; }

    public IList<Comment> Comments { get; set; }
}

물론 서버에서 JSON으로 항목을 변환할 때 관련 엔티티에는 관심이 없습니다.이러한 이유로 JSON에 포함되지 않도록 관련 속성에 속성을 넣을 수 있습니다.

public class Post
{
    public int Id { get; set; }

    public string Body { get; set; }

    [ScriptIgnore]   
    public IList<Comment> Comments { get; set; }
}

그러면 JSON serializer가 세부 정보 편집기에서 편집하지 않을 관련 속성을 무시하게 됩니다.

ToJson()확장 코드

여기에 마지막으로 추가할 것은 확장 메서드 코드는 다음과 같습니다.

public static class ObjectExtensions
{
    /// <summary>
    /// Serializes this object instance to JSON string.
    /// </summary>
    /// <param name="instance">Object instance being extended.</param>
    /// <returns>Returns a JSON string that represents current object instance.</returns>
    public static string ToJson(this object instance)
    {
        JavaScriptSerializer serializer = new JavaScriptSerializer();
        // register custom class converters
        serializer.RegisterConverters(...);
        return serializer.Serialize(instance);
    }

    /// <summary>
    /// Serializes this object instance to JSON string.
    /// </summary>
    /// <param name="instance">Object instance being extended.</param>
    /// <param name="recursionDepth">Serialization recursion limit depth.</param>
    /// <returns>Returns a JSON string that represents current object instance.</returns>
    public static string ToJson(this object instance, int recursionDepth)
    {
        JavaScriptSerializer serializer = new JavaScriptSerializer();
        // register custom class converters
        serializer.RegisterConverters(...);
        serializer.RecursionLimit = recursionDepth;
        return serializer.Serialize(instance);
    }
}

엔티티가 너무 복잡할 때 어떻게 해야 합니까?

상위 접근 방식은 엔티티가 너무 복잡하지 않을 때 유용합니다.다음과 같은 경우:

• 엔티티가 복잡하거나 긴 데이터를 가지고 있습니다(직렬화된 문자열 측면에서 긴).
• 모든 항목에 대해 JSON 개체를 확인하는 데 너무 많은 시간이 소요됩니다.
• 마스터 목록 표시 시 알 수 없는 JSON 개체

그러면 항상 단일 엔티티에 대한 원격 Ajax 호출을 서버로 보내고 다음 중 하나를 반환할 수 있습니다.

• 대화 상자 템플릿에 사용할 JSON 개체
• 편집기를 사용하여 부분 보기

객체 인스턴스를 HTML 또는 JSON으로 변환하는 것은 실질적으로 유사한 작업이기 때문에 두 번째 접근 방식이 더 좋습니다.그러나 두 번째 경우에는 클라이언트 측 템플릿 처리가 필요하지 않습니다.

하지만 원격 요청을 사용할 수 있다고 해서 사용하지는 마십시오.당면한 문제에 대해 더 쉽고 더 나은 접근 방식을 사용합니다.

1: jQuery 템플릿 API 참조

언급URL : https://stackoverflow.com/questions/7759119/commonly-accepted-approach-in-mvc-for-form-within-jquery-dialog