IT story

내 옆에 아무도 ASP.NET MVC를 얻지 못합니까?

hot-time 2020. 6. 20. 09:37
반응형

내 옆에 아무도 ASP.NET MVC를 얻지 못합니까? [닫은]

CTP 이후로 ASP.NET MVC를 다루어 왔으며 많은 일을 좋아하지만 얻지 못하는 것이 있습니다.

예를 들어, 나는 beta1을 다운로드했고 작은 개인 사이트 / 이력서 / 블로그를 함께 가지고 있습니다. ViewSinglePost 뷰의 스 니펫은 다음과 같습니다.

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

역겨운! (또한 HTML에는 임시 자리 표시 자 HTML이 있으므로 기능이 작동하면 실제 디자인을 만들 것입니다) .

내가 뭔가 잘못하고 있습니까? 나는 고전적인 ASP에서 많은 어두운 날을 보냈기 때문에이 태그 수프는 그것을 강력하게 상기시킵니다.

모든 사람이 당신이 더 깔끔한 HTML을 할 수있는 방법을 설교합니다. 뭔지 맞춰봐? 모든 사람의 1 %가 출력 된 HTML을 봅니다. 나에게, 유지하기 쉬운 코드가있는 한 Webforms가 렌더링 된 HTML에서 들여 쓰기를 엉망으로 만들지 않아도됩니다.

그래서, 다이 하드 webforms 사람을 변환하십시오. 왜 내가 이것을 위해 멋지게 형성된 ASPX 페이지를 포기해야합니까?

편집 : "temp Html / css"줄을 굵게 표시하여 사람들이 그것에 대해 설명합니다.

웹 양식에 비해 MVC 동시에 페이지 출력을보다 제어 HTML 생성에 낮은 수준의 접근 방식 과 높은 수준, 더 구조적 중심의 접근 방식. Web Forms와 MVC를 캡처하고 고전적인 Web Forms 트랩에 속하지 않는 한 많은 상황에서 비교가 Web Forms에 유리하다고 생각하는 이유를 보여 드리겠습니다.

웹 양식

Web Forms 모델에서 페이지는 브라우저의 페이지 요청과 직접 일치합니다. 따라서 사용자를 서적 목록으로 안내하는 경우 "Booklist.aspx"라는 페이지가있을 수 있습니다. 해당 페이지에서 해당 목록을 표시하는 데 필요한 모든 것을 제공해야합니다. 여기에는 데이터 가져 오기, 비즈니스 로직 적용 및 결과 표시를위한 코드가 포함됩니다. 페이지에 영향을주는 아키텍처 또는 라우팅 논리가있는 경우 페이지의 아키텍처 논리도 코딩해야합니다. 좋은 Web Forms 개발에는 일반적으로 별도의 (테스트 가능한) DLL로 지원 클래스 세트를 개발하는 것이 포함됩니다. 이 수업은 비즈니스 로직, 데이터 액세스 및 아키텍처 / 라우팅 결정을 처리합니다.

MVC

MVC는 웹 애플리케이션 개발에 대해보다 "건축적인"관점을 취합니다. 즉, 구축 할 표준화 된 스캐 폴드를 제공합니다. 또한 기존 아키텍처 내에서 모델, 뷰 및 컨트롤러 클래스를 자동으로 생성하기위한 도구를 제공합니다. 예를 들어 Ruby on Rails (여기서는 "Rails"만)와 ASP.NET MVC에서 웹 애플리케이션 아키텍처의 전체 모델을 반영하는 디렉토리 구조로 시작해야합니다. 뷰, 모델 및 컨트롤러를 추가하려면 Rails의 "Rails 스크립트 / 생성 스캐 폴드 {modelname}"(ASP.NET MVC는 IDE에서 유사한 명령을 제공함)과 같은 명령을 사용합니다. 결과 컨트롤러 클래스에는 색인 (표시 목록), 표시, 새로 작성 및 편집 및 삭제 (적어도 Rails에서는 MVC가 유사 함)에 대한 메소드 ( "Actions")가 있습니다. 기본적으로이 "Get"

디렉토리와 파일의 레이아웃은 MVC에서 중요합니다. 예를 들어 ASP.NET MVC에서 "Book"개체 의 Index 메서드에는 "Return View ();"라는 한 줄만있을 것입니다. MVC의 마법을 통해 책 모델을 책을 표시하는 코드를 찾을 수있는 "/View/Books/Index.aspx"페이지로 보냅니다. 논리가 조금 더 명확하고 덜 "매직"하지만 Rails의 접근 방식은 비슷합니다. MVC 앱 의 보기 페이지는 일반적으로 웹 양식 페이지보다 간단합니다. 라우팅, 비즈니스 로직 또는 데이터 처리에 대해 걱정할 필요가 없기 때문입니다.

비교

MVC의 장점은 문제를 명확하게 구분하고보다 생산적인 HTML / CSS / AJAX / 자바 중심의 모델을 생성하는 것입니다. 이를 통해 테스트 가능성이 향상되고보다 표준화 된 디자인이 제공되며보다 "Web 2.0"유형의 웹 사이트가 열립니다.

그러나 몇 가지 중요한 단점도 있습니다.

첫째, 데모 사이트를 쉽게 이용할 수 있지만 전체 아키텍처 모델에는 상당한 학습 곡선이 있습니다. 그들이 "컨벤션 오버 컨벤션 (Convention Over Configuration)"이라고 말하면 배우는 책의 관습이 중요하다는 것을 알기 전까지는 좋은 소리를냅니다. 게다가, 당신 이 명백한 호출보다는 마법에 의존 하기 때문에 무슨 일이 일어나고 있는지 알아내는 것은 종종 약간 화나 있습니다. 예를 들어 "Return View ();" 위에 전화? 다른 행동에서 똑같은 전화를 찾을 수 있지만 다른 장소로갑니다. MVC 규칙 을 이해하면 then you know why this is done. However, it certainly doesn't qualify as an example of good naming or easily understandable code and it is much harder for new developers to pick up than Web Forms (this isn't just opinion: I had a summer intern learn Web Forms last year and MVC this year and the differences in productivity were pronounced - in favor of Web Forms). BTW, Rails is a bit better in this regard although Ruby on Rails features dynamically-named methods that take some serious getting-used-to as well.

둘째, MVC는 사용자가 기존 CRUD 스타일 웹 사이트를 구축하고 있다고 암시합니다. 아키텍처 결정 및 특히 코드 생성기는 모두 이러한 유형의 웹 응용 프로그램을 지원하도록 구축되었습니다. CRUD 응용 프로그램을 구축 할 때 입증 된 아키텍처를 채택하거나 아키텍처 설계를 싫어하는 경우 MVC를 고려해야합니다. 그러나 CRUD 이상을 수행하거나 아키텍처와 합리적으로 경쟁력이 있다면 MVC는 기본 라우팅 모델을 실제로 마스터 할 때까지 직선 자켓처럼 느껴질 수 있습니다 (WebForms 앱에서 라우팅하는 것보다 훨씬 더 복잡합니다). 그럼에도 불구하고, 나는 항상 모델과 싸우고 예기치 않은 결과에 대해 걱정하는 것처럼 느꼈습니다.

셋째, Linq에 신경 쓰지 않는다면 (Linq-to-SQL이 사라질까 두려워하거나 Linq-to-Entities가 과도하게 생산되고 전력이 부족하다는 것을 알기 때문에) 원치 않습니다. Linq 주위에 ASP.NET MVC 스캐 폴딩 도구가 구축되어 있기 때문에이 길을 걸을 수 있습니다. Rails의 데이터 모델은 또한 SQL에 익숙한 경우 (특히 TSQL 및 저장 프로 시저에 정통한 경우) 달성 할 수있는 것과 비교할 때 매우 어색합니다.

넷째, MVC 지지자들은 종종 MVC 뷰가 웹의 HTML / CSS / AJAX 모델에 더 가깝다는 점을 지적합니다. 예를 들어, 내용을 바꾸고 HTML 컨트롤에 배치하는 Vew 페이지의 작은 코드 호출 인 "HTML Helpers"는 Web Forms 컨트롤보다 Javascript와 통합하기가 훨씬 쉽습니다. 그러나 ASP.NET 4.0에는 컨트롤 이름을 지정할 수있는 기능이 도입되어 이러한 이점을 크게 제거했습니다.

다섯째, MVC 순수 주의자들은 종종 Viewstate를 무시합니다. 어떤 경우에는 그렇게 할 수 있습니다. 그러나 Viewstate는 훌륭한 도구이자 생산성에 도움이 될 수 있습니다. 비교해 보면 MVC 앱에서 타사 웹 컨트롤을 통합하는 것보다 Viewstate를 처리하는 것이 훨씬 쉽습니다. MVC의 제어 통합이 쉬워 질 수 있지만, 내가 본 모든 현재의 노력은 이러한 제어를 뷰의 Controller 클래스에 다시 연결하기 위해 (그런지 다소 거친) 코드를 작성해야합니다 (즉 , MVC 모델 을 해결 하기 위해) ).

결론

나는 여러 가지면에서 MVC 개발을 좋아한다 (장거리에서는 Rails를 ASP.NET MVC보다 선호하지만). 또한 ASP.NET MVC가 ASP.NET Web Forms의 "반 패턴"이라는 생각의 함정에 빠지지 않는 것이 중요하다고 생각합니다. 그것들은 다르지만 완전히 외계인은 아니며 두 가지를위한 공간이 있습니다.

그러나 Web Forms 개발을 선호 합니다. 대부분의 작업 에서는 작업을 수행 하기가 더 쉽습니다 (CRUD 양식 집합 생성 제외). MVC는 또한 어느 정도 과도한 이론 으로 인해 어려움을 겪고있는 것으로 보인다 . 실제로 페이지 지향 ASP.NET을 알고 있지만 MVC를 시도하는 사람들이 SO에 대해 여기에서 묻는 많은 질문을 살펴보십시오. 예외없이, 개발자가 농구를 뛰어 넘거나 거대한 학습 곡선을 견디지 않으면 기본 작업을 수행 할 수 없다는 것을 알게되면 치아가 많이 나옵니다. 이것은 나의 책에서 MVC 우수 웹 양식을 만드는 것입니다 : MVC는 당신이 지불하게 실제 가격 , 또는 더 나쁜 아직 조금 더 테스트 용이성을 얻기 위해 간단하게 볼 수 멋진 당신은을 사용하고 있기 때문에최신 기술.

업데이트 : 나는 의견 섹션에서 크게 비판을 받았다. 따라서 나는 몇 달 동안 Rails와 ASP.NET MVC를 배우면서 다음 큰 일을 실제로 놓치지 않았는지 확인했습니다! 물론, 질문에 대한 균형 잡힌 적절한 답변을 제공하는 데 도움이됩니다. 위의 답변은 의견이 일치하지 않는 경우를 대비하여 초기 답변을 크게 재 작성 한 것입니다.

MVC를 더 자세히 살펴 보는 동안 잠시 동안 주요 mea culpa로 끝날 것이라고 생각했습니다. 결국 Web Forms 아키텍처 및 테스트 가능성에 더 많은 에너지를 소비해야한다고 생각하지만 MVC는 실제로 그 요구에 응답하지 않습니다. 따라서 초기 답변에 대한 지적 비판을 제공 한 사람들에게 진심으로 "감사합니다".

이것을 종교적 전투 로 보았고 공감대 홍수를 끊임없이 설계 한 사람들에 대해, 나는 왜 당신이 귀찮게하는지 이해하지 못합니다 (여러 번에 서로 몇 초 안에 20 개 이상의 공표가 확실히 정상이 아닙니다). 이 답변을 읽고 점수가 다른 답변보다 훨씬 낮다는 점을 감안할 때 내 답변에 대해 정말로 "잘못된"것이 있는지 궁금한 경우, 일반적인 의미보다 동의하지 않는 소수의 사람들에 대해 더 많은 것을 말하십시오. 커뮤니티 (전체적으로 100 번 이상 공표되었습니다).

사실 많은 개발자가 MVC를 신경 쓰지 않으며 실제로 블로그가 나타내는 것처럼 MS 내에서도 소수의 견해가 아닙니다.

MVC를 사용하면 출력을보다 강력하게 제어 할 수 있으며,이 컨트롤을 사용하면 제대로 디자인되지 않은 HTML, 태그 수프 등을 작성할 위험이 커집니다.

그러나 동시에 이전에는 없었던 몇 가지 새로운 옵션이 있습니다 ...

  1. 페이지 및 페이지 내의 요소를보다 강력하게 제어
  2. ViewState와 같이 출력에서 ​​"정크"가 적거나 요소의 ID가 너무 길다 (오해하지 말고 ViewState를 좋아한다)
  3. Javascript를 사용하여 클라이언트 측 프로그래밍을 수행하는 더 나은 기능
  4. MVC뿐만 아니라 JsonResult는 매끄 럽습니다 ...

이제 WebForms로 이러한 작업을 수행 할 수는 없지만 MVC를 사용하면 더 쉽게 할 수 있습니다.

서버 컨트롤 등을 활용할 수 있기 때문에 웹 응용 프로그램을 빠르게 만들어야하는 경우에도 여전히 WebForms를 사용합니다. WebForms는 입력 태그 및 제출 버튼의 모든 세부 정보를 숨 깁니다.

부주의 한 경우 WebForms와 MVC 모두 절대 가비지가 가능합니다. 항상 그렇듯이 신중한 계획과 신중한 디자인은 MVC이든 WebForms이든 관계없이 양질의 애플리케이션이 될 것입니다.

[최신 정보]

위로가 될 경우 MVC는 Microsoft의 새로운 기술입니다. WebForms가 남아있을뿐만 아니라 계속 개발 될 것이라는 많은 게시물이 있습니다 ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... 등등...

MVC가 취항하는 노선에 관심이있는 분들을 위해 "남자들"에게 피드백을 제공 할 것을 제안합니다. 지금까지 듣고있는 것 같습니다!

ASP.NET MVC에 대한 대부분의 반대 의견은 아키텍처에서 가장 "선택적인"모듈 형 비트 중 하나 인 뷰를 중심으로 보입니다. NVelocity , NHaml , Spark , XSLT 및 기타 뷰 엔진을 쉽게 교체 할 수 있습니다 (모든 릴리즈에서 더 쉬워지고 있습니다). 많은 것들이 프리젠 테이션 로직과 포맷팅을위한 더 간결한 구문을 가지고 있으며, 방출 된 HTML을 여전히 완벽하게 제어합니다.

그 외에도 거의 모든 비판이 기본보기에서 <% %> 태그로 표시되고 이것이 얼마나 "추악"한지에 대한 것 같습니다. 이러한 의견은 종종 WebForms 접근 방식에 익숙해 져 대부분의 기존 ASP 추악함을 코드 숨김 파일로 옮깁니다.

코드 숨김을 "잘못"하지 않아도 리피터의 OnItemDataBound와 같은 항목이 있습니다.이 항목은 "태그 수프"와는 다른 방식 으로 미학적으로보기 흉한 방법입니다. foreach 루프는 특히 루프 이외의 ASP.NET 기술에서 MVC를 사용하는 경우 해당 루프의 출력에 변수를 포함하더라도 훨씬 쉽게 읽을 수 있습니다. foreach 루프를 이해하는 데 중계기에서 해당 필드를 수정하는 방법은 OnItemDataBound (및 변경해야하는 올바른 요소인지 확인하는 쥐의 둥지)를 망쳐 놓는 것임을 이해하는 것보다 Google-fu가 훨씬 적습니다.

ASP 태그 수프 중심의 "스파게티"의 가장 큰 문제는 HTML 사이에 데이터베이스 연결과 같은 것들을 넣는 것에 관한 것이 었습니다.

<% %>를 사용하여 그렇게 된 것은 인과 관계가 아닌 클래식 ASP의 스파게티 특성과의 상관 관계 일뿐입니다. 뷰 로직을 HTML / CSS / Javascript로 유지하고 프리젠 테이션 을 수행하는 데 필요한 최소한의 로직을 유지 하면 나머지는 구문입니다.

특정 기능을 WebForms와 비교할 때 MVC 솔루션이 실제로 훨씬 단순하지 않도록 디자이너가 생성 한 모든 C # 및 코드 숨김 C #을 .aspx 코드와 함께 포함해야합니다. .

반복 가능한 표현 논리 비트에 대한 부분 뷰의 신중한 사용과 결합하면 실제로 훌륭하고 우아 할 수 있습니다.

개인적으로, 나는 초기 학습 내용의 대부분이 테스트 중심, 제어 역전 등 거의 독점적 으로이 목적에 더 초점을 맞추기를 바랍니다. 다른 것들이 전문가가 반대하는 반면, 참호에있는 사람들은 더 가능성이 높습니다 "태그 수프"에 반대합니다.

어쨌든, 이것은 아직 베타 버전 인 플랫폼입니다. 그럼에도 불구하고 대부분의 Microsoft- 베타 기술보다 더 많은 배포 및 Microsoft 이외의 개발자가 실제 물건을 구축하는 방법이 늘어나고 있습니다. 따라서 버즈는 주변 인프라 (문서, 안내 패턴 등)보다 더 멀리있는 것처럼 보이게하는 경향이 있습니다. 이 시점에서 진정으로 사용할 수 있으면 그 효과가 증폭됩니다.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

포함 된 CSS를 포함하지 않고이 작업을 수행하는 방법을 묻는 다른 게시물을 만들 수 있습니다.

참고 : ViewData.Model은 다음 릴리스에서 모델이됩니다.

그리고 사용자 컨트롤의 도움으로 이것은

<% Html.RenderPartial("Pager", Model.PagerData) %>

여기서 PagerData는 작업 처리기에서 익명 생성자를 통해 초기화됩니다.

편집 :이 문제에 대한 WebForm 구현의 모양이 궁금합니다.

사람들이 코드에 대한 관심을 멈추는 시점이 확실하지 않습니다.

HTML은 작업의 가장 공개적인 표시이며, 메모장, 메모장 ++ 및 기타 일반 텍스트 편집기를 사용하여 많은 웹 사이트를 구축하는 개발자가 많이 있습니다.

MVC는 웹 양식에서 제어권을 다시 가져오고 상태 비 저장 환경에서 작업하며 일반적으로이 패턴을 구현할 때 발생하는 추가 작업없이 Model View Controller 디자인 패턴을 구현하는 것입니다.

제어, 깔끔한 코드 및 MVC 디자인 패턴을 사용하려는 경우 이는 마크 업 작업이 마음에 들지 않으면 마크 업의 기형에 신경 쓰지 말고 ASP.Net Web Forms를 사용하십시오.

어느 쪽이든 마음에 들지 않으면 마크 업에서 거의 많은 작업을 수행하게 될 것입니다.

편집 나는 또한 Web Forms와 MVC가 자신의 자리를 가지고 있다고 진술해야하며, 나는 하나가 다른 것보다 낫다는 것을 말하지 않았고 각 MVC는 마크 업에 대한 통제력을 회복하는 힘을 가지고 있다고 말했다.

네가 빠진 것 같아 먼저, Response.Write가 필요하지 않습니다 <%= %>. 태그를 사용할 수 있습니다 . 둘째, 일반적인 작업을 수행하기 위해 자체 HtmlHelper 확장을 작성할 수 있습니다. 셋째, 약간의 서식 지정이 많은 도움이됩니다. 넷째,이 모든 것이 여러 다른 뷰간에 공유되도록 사용자 정의 컨트롤에 붙어있을 수 있으므로 기본 뷰의 전체 마크 업이 더 깨끗합니다.

마크 업이 원하는만큼 깔끔하지는 않지만 임시 변수를 사용하면 상당히 정리할 수 있습니다.

이제는 그렇게 나쁘지 않으며 SO 형식으로 포맷하지 않아도 더 좋습니다.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

MVC의 가장 큰 장점은 오랫동안 사용되어 온 개념적 프레임 워크이며 가로 및 세로로 확장되는 웹 응용 프로그램과 워크 스테이션 응용 프로그램을 모두 생산할 수있는 생산적이고 강력한 방법으로 입증되었습니다. 알토와 스몰 토크로 바로 돌아갑니다. 마이크로 소프트는 파티에 늦었다. 우리가 ASP.NET MVC로 지금 가지고있는 것은 정말 원시적입니다. 왜냐하면 따라야 할 일이 너무 많기 때문입니다. 그러나 젠장, 그들은 새 릴리스를 빠르고 격렬하게 쏟아 붓고 있습니다.

Ruby on Rails의 가장 큰 장점은 무엇입니까? Rails는 MVC입니다. 입소문으로 프로그래머가 생산성을 높일 수있는 방법이 되었기 때문에 개발자들은 전환을 해왔습니다.

대단한 일입니다. MVC와 jQuery의 암시 적 보증은 플랫폼 중립적이라는 것이 중요하다는 점을 Microsoft가 받아들이는 요령입니다. 그리고 중립적 인 점은 Web Forms와 달리 Microsoft는 개념적으로 귀하를 잠글 수 없다는 것입니다. 코드 자체가 아닌 이식 가능한 MVC 개념이기 때문에 모든 C # 코드를 가져 와서 다른 언어 (예 : PHP 또는 java-이름 지정)로 완전히 다시 구현할 수 있습니다. 또한 코드를 거의 변경하지 않고 디자인을 변경하지 않고도 디자인을 가져 와서 워크 스테이션 앱으로 구현할 수 있다는 것이 얼마나 큰지 생각해보십시오. Web Forms를 사용해보십시오.

Microsoft는 Web Forms가 다음 VB6이되지 않기로 결정했습니다.

Rob Conery의 게시물 을 보라. 나는 그것을 말할 것이다 : 당신은 MVC를 배워야한다.

웹 양식에 비해 ASP.NET MVC 프레임 워크의 두 가지 주요 장점은 다음과 같습니다.

  1. 테스트 가능성 -웹 양식의 UI 및 이벤트는 테스트가 불가능합니다. ASP.NET MVC를 사용하면 단위 테스트 컨트롤러 작업과 렌더링 뷰가 쉽습니다. 여기에는 초기 개발 비용이 들지만, 연구 결과에 따르면 앱을 리팩터링하고 유지 관리해야 할 때 장기적으로 이점이 있습니다.
  2. 렌더링 된 HTML을보다 효율적으로 제어 -렌더링 된 HTML을 아무도 보지 않기 때문에 신경 쓰지 않아도됩니다. 그것이 HTML 형식을 올바르게 설정 한 유일한 이유라면 유효한 불만입니다. SEO, CSS 및 자바 스크립트에서 id 선택기를 더 자주 사용하는 기능, viewstate 부족으로 인한 페이지 풋 프린트가 작고 엄청나게 긴 id (ctl00_etcetcetc)를 포함하여 올바른 형식의 HTML을 원하는 많은 이유가 있습니다.

이제 이러한 이유들로 인해 ASP.NET MVC가 웹 양식보다 흑백 방식으로 나아지는 것은 아닙니다. ASP.NET MVC는 웹 양식과 마찬가지로 장단점이 있습니다. 그러나 ASP.NET MVC에 대한 대부분의 불만은 프레임 워크의 실제 결함보다는 사용 방법에 대한 이해 부족에서 비롯된 것 같습니다. 코드가 적절하지 않거나 올바르게 보이지 않는 이유는 몇 년 동안 웹 양식 경험이 있고 1-2 개월의 ASP.NET MVC 경험 만 있기 때문일 수 있습니다.

여기서 문제는 ASP.NET MVC가 흔들 리거나 빨라지는 것이 아니라 새롭고 올바르게 사용하는 방법에 대한 동의가 거의 없다는 것입니다. ASP.NET MVC는 앱에서 발생하는 상황을보다 세밀하게 제어합니다. 접근 방식에 따라 특정 작업을 더 쉽고 어렵게 만들 수 있습니다.

안녕하세요, MVC로 전환하는 데 어려움을 겪고 있습니다. 나는 고전적인 ASP의 팬이 아니며 MVC 렌더링은 그 당시 많은 것을 상기시켜줍니다. 그러나 MVC를 많이 사용할수록 더 많이 성장합니다. 나는 webforms 사람이며 (많은 사람들처럼) 지난 몇 년 동안 데이터 그리드 등을 다루는 데 익숙해졌습니다. MVC를 사용하면 제거됩니다. HTML 헬퍼 클래스가 답입니다.

최근에 나는 MVC에서 "그리드"에 페이징을 추가하는 가장 좋은 방법을 찾으려고 2 일을 보냈다. 이제 webforms를 사용하면 곧바로 이것을 채울 수 있습니다. 그러나 나는 이것을 말할 것입니다 ... 일단 MVC 용으로 작성된 페이징 도우미 클래스가 있으면 구현하기가 매우 간단 해졌습니다. 나에게 웹폼보다 훨씬 쉽다.

즉, 일관된 HTML 도우미가 있으면 MVC가 훨씬 개발자 친화적이라고 생각합니다. 가까운 장래에 웹에 수많은 HTML 도우미 클래스가 나타날 것입니다.

내가 처음 webforms을봤을 때 말한 것이기 때문에 재미있다.

아직 asp.net MVC를 얻지 못했음을 인정합니다. 내가하고있는 사이드 프로젝트에서 사용하려고하지만 꽤 느리게 진행됩니다.

웹 양식에서 너무 쉽게 할 수있는 일을 할 수 없다는 것 외에도 태그 수프를 발견했습니다. 그것은 실제로 그 관점에서 한 단계 뒤로 물러서는 것 같습니다. 나는 배우면서 나아질 것으로 기대합니다.

지금까지 MVC를 사용하는 가장 큰 이유는 HTML을 완전히 제어하는 ​​것입니다. 또한 asp.net MVC가 웹 양식보다 더 많은 페이지를 제공 할 수 있으며 이와 관련이있을 수 있으며 개별 페이지 크기는 평균 웹 양식 페이지보다 작습니다.

HTML이 주요 브라우저에서 작동하는 한 HTML의 모양은 중요하지 않지만 페이지로드 속도 및 차지하는 대역폭은 중요합니다.

나는 그것이 추악한 마크 업이라는 것에 완전히 동의하지만, 추악한 뷰 구문을 사용하여 ASP.NET MVC를 전체적으로 작성하는 것은 불공평하다고 생각합니다. 뷰 구문은 Microsoft의 관심을 가장 적게 받았으며 곧 그것에 대해 무언가를 기대하고 있습니다.

다른 답변은 MVC의 장점을 전체적으로 논의 했으므로 뷰 구문에 중점을 둘 것입니다.

HTML을 생성하는 Html.ActionLink 및 기타 방법을 사용하도록 권장하는 것은 잘못된 방향으로의 단계입니다. 이것은 서버 제어의 부족이며, 존재하지 않는 문제를 해결하고 있습니다. 코드에서 태그를 생성하려는 경우 HTML을 전혀 사용하지 않는 이유는 무엇입니까? DOM 또는 다른 모델을 사용하여 컨트롤러에 컨텐츠를 구축 할 수 있습니다. 알았어, 안좋아 보여? 그렇습니다. 우려가 분리 되었기 때문에 우리는 견해를 가지고 있습니다.

올바른 방향은 뷰 구문을 HTML과 최대한 비슷하게 만드는 것입니다. 잘 설계된 MVC는 컨텐츠에서 코드를 분리 할뿐만 아니라 뷰에 대한 레이아웃 전문가 (ASP.NET을 모르더라도)에 대해 전문 지식을 가진 사람들이 작업을 능률화 할 수 있도록해야합니다. 나중에 개발자로 들어가서 모형을 실제로 동적으로 만들 수 있습니다. 뷰 구문이 HTML과 매우 유사 해 레이아웃 사람들이 DreamWeaver 또는 현재 널리 사용되는 레이아웃 도구를 사용할 수있는 경우에만이 작업을 수행 할 수 있습니다. 한 번에 수십 개의 부지를 구축 할 수 있으며 생산 효율성을 위해 이러한 방식으로 확장해야합니다. "언어"보기가 어떻게 작동하는지 볼 수있는 예를 들어 보겠습니다.

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

여기에는 몇 가지 장점이 있습니다.

  • 더 좋아 보인다
  • 더 간결한
  • HTML과 <% %> 태그 사이에 펑키 컨텍스트 전환이 없음
  • 이해하기 쉬운 키워드를 쉽게 이해할 수 있습니다 (비 프로그래머도이를 수행 할 수 있음-병렬화에 적합)
  • 가능한 많은 로직을 컨트롤러 (또는 모델)로 다시 이동
  • HTML을 생성하지 않음-다시 말하면 Html을 엉망으로 만들지 않고도 누군가가 스타일을 지정할 수있는 곳을 쉽게 알 수 있습니다. 행동 양식
  • 코드에는 브라우저에 뷰를 일반 HTML로로드 할 때 렌더링되는 샘플 텍스트가 포함되어 있습니다.

그렇다면이 구문은 정확히 무엇을합니까?

mvc : inner = ""-따옴표 안에있는 내용이 평가되고 태그의 내부 HTML이 결과 문자열로 바뀝니다. (샘플 텍스트가 바뀝니다)

mvc : outer = ""-따옴표 안에있는 내용이 평가되고 태그의 외부 HTML이 결과 문자열로 바뀝니다. (또 샘플 텍스트가 바뀝니다.)

{}-<% = %>와 비슷한 속성 안에 출력을 삽입하는 데 사용됩니다

mvc : if = ""-qoutes는 평가할 부울 표현식입니다. if의 끝은 HTML 태그가 닫히는 곳입니다.

mvc : 다른

mcv : elseif = ""-...

mvc : foreach

이제 나는 여기서 만 말할 수 있습니다.

IMO, 당신이 열심히 일하는 사람이라면 전환은 당신을위한 것이 아닙니다. WebForms를 좋아한다면 필요한 것을 달성 할 수 있기 때문입니다. 그 목표도 마찬가지입니다.

Webforms는 개발자 로부터 HTML을 추상화하는 작업을 잘 수행합니다 . 이것이 목표라면 Web Forms를 고수하십시오. 데스크탑 개발을 오늘날처럼 만들어 낸 훌륭한 "클릭 앤 드래그"기능이 있습니다. 다양한 기능을 제공 할 수있는 많은 포함 된 컨트롤 (및 다양한 타사 컨트롤)이 있습니다. 데이터베이스에서 DataSource와 직접 연결된 "그리드"를 드래그 할 수 있습니다. 인라인 편집, 페이징 등이 내장되어 있습니다.

현재 ASP.NET MVC는 타사 컨트롤 측면에서 매우 제한적입니다. 다시 말하지만, 많은 기능이 연결되어있는 Rapid Application Development를 좋아한다면 변환을 시도해서는 안됩니다.

이 모든 것이 말하면 ASP.NET이 빛나는 곳입니다.-TDD. Nuff는 코드를 테스트 할 수 없다고 말했다.

  • 우려의 분리. 이것이 MVC 패턴의 중추입니다. Web Forms에서이 작업을 수행 할 수 있음을 충분히 알고 있습니다. 그러나 나는 부과 된 구조를 좋아한다. Web Forms에서는 디자인과 논리를 혼합하기가 너무 쉽습니다. ASP.NET MVC를 사용하면 팀의 다른 구성원이 응용 프로그램의 다른 섹션에서보다 쉽게 ​​작업 할 수 있습니다.

  • 다른 곳에서 왔습니다 : 제 배경은 CakePHP와 Ruby on Rails입니다. 따라서 내 편견이 어디에 있는지 분명합니다. 그것은 당신이 편한 것에 관한 것입니다.

  • 학습 곡선 : 마지막 지점을 확장합니다. 다른 요소의 기능을 변경하려는 "템플릿"이라는 아이디어를 싫어했습니다. 파일 숨김 코드에서 많은 디자인이 이루어 졌다는 사실이 마음에 들지 않았습니다. 내가 이미 HTML과 CSS에 친숙 할 때 배워야 할 것이 하나 더 있습니다. 페이지의 "요소"에서 무언가를하고 싶다면, "div"또는 "span"을 고수하고 ID를 때리거나 내립니다. Web Forms에서는이 작업을 수행하는 방법을 조사해야합니다.

  • 웹의 현재 상태 "디자인": jQuery와 같은 자바 스크립트 라이브러리가 점점 일반화되고 있습니다. Web Forms가 ID를 엉망으로 만드는 방식은 Visual Studio 외부에서 구현을 더욱 어렵게 만듭니다.

  • 더 많은 분리 (디자인) : 많은 디자인이 컨트롤에 연결되어 있기 때문에 외부 디자이너 (Web Forms 제외) 지식이 Web Forms 프로젝트에서 작동하기가 매우 어렵습니다. Web Forms는 모두 끝이되도록 만들어졌습니다.

다시 말하지만, 이러한 이유 중 다수는 Web Forms에 익숙하지 않기 때문입니다. Web Forms 프로젝트 (올바로 설계된 경우)는 ASP.NET MVC의 이점을 "가장 많이"가질 수 있습니다. 그러나 이것이 바로 경고입니다. "올바로 설계된 경우". 그리고 그것은 Web Forms에서 수행하는 방법을 모르는 것입니다.

Web Forms에서 훌륭한 작업을 수행하는 경우 효율적이고 효과가 있습니다.

기본적으로 장단점 목록을 사용하여 두 가지 모두에 대해 빠른 검토를 수행하고 (편견없는 소스를 찾아보십시오 [행운]) 목표에 맞는 것을 평가하고이를 바탕으로 선택하십시오.

결론은 저항을 최소화하고 목표를 달성하는 데 가장 도움이되는 경로를 선택하는 것입니다. Web Forms는 매우 성숙한 프레임 워크이며 앞으로 더 나아질 것입니다. ASP.NET MVC는 또 다른 대안입니다. Ruby on Rails 및 CakePHP 개발자 (나 같은 : P)

Java EE의 JSP는 처음 제안되었을 때 이와 같이 생겼습니다 – 추악한 스크립틀릿 코드.

그런 다음 태그 라이브러리를 제공하여 HTML 태그를 더 많이 만들었습니다. 문제는 누구나 태그 라이브러리를 작성할 수 있다는 것입니다. 사람들이 HTML을 생성하는 태그 라이브러리에 많은 논리 (및 스타일)를 포함 시켰기 때문에 일부 결과는 비참했습니다.

최선의 해결책은 JSP 표준 태그 라이브러리 (JSTL)라고 생각합니다. HTML 표준 인 "표준"이며 사람들이 로직을 페이지에 넣지 못하게합니다.

추가 이점은 웹 디자이너와 개발자 간의 경계를 유지한다는 것입니다. 내가 보는 좋은 사이트는 미적 감각과 유용성을 위해 디자인 된 사람들이 디자인 한 것입니다. 그들은 페이지와 CSS를 배치하고 동적 데이터 비트를 추가하는 개발자에게 전달합니다. 이러한 선물이 부족한 개발자라고 할 때 개발자에게 수프에서 견과류에 이르기까지 웹 페이지를 작성하도록 요청할 때 중요한 것을 제공한다고 생각합니다. Flex와 Silverlight는 디자이너가 JavaScript와 AJAX를 잘 알지 못할 것이므로 같은 문제로 어려움을 겪을 것입니다.

.NET에 JSTL과 비슷한 경로가 있다면 조사해 보는 것이 좋습니다.

이 샘플이 ASP .NET MVC 3 이후 기본값 인 반짝이는 새로운 Razor 뷰 엔진 과 어떻게 보이는지 공유한다고 생각했습니다 .

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

그것에 문제가 있습니까?
또한 실제로 CSS 스타일을 인라인해서는 안됩니다. 왜 두 곳이 아닌 세 곳에서 무효를 확인합니까? 여분의 div상처는 거의 없습니다. 이것이 내가하는 방법입니다.

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

ASP.NET MVC 프로젝트와 직접 대화 할 수는 없지만 일반적으로 MVC 프레임 워크는 웹 응용 프로그램 개발 을 지배하게 되었습니다.

  1. 데이터베이스 운영, "비즈니스 로직"및 프레젠테이션을 공식적으로 분리합니다.

  2. 개발자는 HTML / CSS / 자바 스크립트를 여러 브라우저 및 해당 브라우저의 향후 버전 에서 작동하도록 조정할 수있는 충분한 유연성을 제공 합니다.

중요한 것은이 마지막 비트입니다. Webforms 및 이와 유사한 기술을 사용하면 공급 업체를 통해 HTML / CSS / Javascript를 작성하게됩니다. 강력한 기능이지만 현재 버전의 Webforms가 차세대 웹 브라우저에서 작동한다는 보장은 없습니다.

그것이보기의 힘입니다. 애플리케이션의 HTML을 완전히 제어 할 수 있습니다. 단점은 뷰의 논리를 최소한으로 유지하고 템플릿 코드를 가능한 한 간단하게 유지하도록 충분히 훈련 을 받아야한다는 것입니다.

이것이 바로 트레이드 오프입니다. Webforms가 당신을 위해 작동하고 MVC가 작동하지 않으면 Webforms 를 계속 사용하십시오.

그것에 대한 나의 좌절의 대부분은 단지 "적절하게"일을하는 방법을 모른다. 미리보기로 출시 된 이후로 우리 모두는 사물을 볼 시간이 약간 있었지만 상당히 바뀌 었습니다. 처음에는 정말 좌절했지만 프레임 워크는 매우 복잡한 UI (읽기 : Javascript)를 매우 빠르게 만들 수있을 정도로 보입니다. 이전에 Webforms를 사용 하여이 작업을 수행 할 수 있음을 이해하지만 모든 것을 올바르게 렌더링하려고 시도하는 것은 엉덩이에 큰 고통이었습니다. 여러 번 나는 정확한 출력을 제어하기 위해 리피터를 사용하게되었고 결국 당신이 가진 스파게티 엉망으로 끝날 것입니다.

같은 혼란을 피하기 위해 도메인, 서비스 계층 및 dto를 조합하여 뷰로 전송했습니다. 뷰 엔진 인 spark와 함께 사용하면 정말 좋습니다. 설정하는 데 약간의 시간이 걸리지 만 일단 응용 프로그램이 복잡해지면 시각적으로 크게 향상되었지만 코드를 현명하게 작성하는 것은 간단합니다.

나는 아마 이것처럼 정확하게하지 않을 것이지만 여기에 당신의 예가 있습니다 :

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

그것은 유지 보수가 쉽고 테스트 가능하며 코드 스프에서 맛있습니다.

테이크 아웃은 깨끗한 코드가 실제로 가능하지만 우리가하는 방식에서 큰 엉덩이 변화입니다. 나는 모든 사람들이 아직 그것을 멍청이 생각하지 않습니다. 나는 아직도 그것을 알아내는 것을 알고있다 ...

Apress의 Steve Sanderson의 최근에 출판 된 'Pro ASP.NET MVC'[1] [2]는 맞춤형 HtmlHelper 확장을 만드는 또 다른 대안을 제안합니다. 그의 샘플 (110 페이지의 4 장에서)은 페이징 된 목록의 예를 사용하지만 상황에 따라 쉽게 조정할 수 있습니다.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

다음과 같은 코드로 뷰에서 호출합니다.

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Phil Haack의 게시물을보고 싶었지만 여기에 없었으므로 http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should 에서 잘라서 붙여 넣습니다. 주석 섹션의 -learn-mvc /

Haacked-2009 년 4 월 23 일-Rob, 당신은 폭동입니다! :) 사람들이 MVC에서 스파게티 코드를 작성하고 "봐! 스파게티!"라고 말하면 재미 있어요. Web Forms에서도 스파게티 코드를 작성할 수 있습니다! 레일, PHP, Java, Javascript로 작성할 수 있지만 Lisp에서는 작성할 수 없습니다. 그러나 내가 아직 Lisp로 아무것도 쓸 수 없기 때문에. 그리고 스파게티 코드를 작성할 때 마카로니를 기대하는 내 접시를 보지 못합니다. 클래식 ASP와 비교할 때 사람들이 자주하는 요점은 클래식 ASP 사람들과 우려를 혼합하는 경향이 있다는 것입니다. 페이지에는 사용자 입력 처리 기능이있는 뷰 로직과 모델 코드 및 비즈니스 로직이 모두 혼합 된 뷰 로직이 있습니다. 그게 스파게티에 관한 것입니다! 하나의 큰 혼란에 모든 우려를 혼합. ASP.NET MVC를 사용하면 패턴을 따를 가능성이 줄어 듭니다. 네, 여전히 뷰에 약간의 코드가있을 수 있지만 모든 뷰 코드 일 것입니다. 이 패턴은 사용자 상호 작용 코드를 넣지 않도록 권장합니다. 컨트롤러에 넣으십시오. 모델 코드를 모델 클래스에 넣습니다. 그곳에. 스파게티가 없습니다. 오오 토로 초밥입니다. :)

나도; ASP.NET MVC보다는 Silverlight에 시간을 할애했습니다. MVC 1.0을 사용해 보았으며 며칠 전에 최신 2.0 베타 1 릴리스를 살펴 보았습니다.

ASP.NET MVC가 웹 양식보다 나은 방법을 느낄 수 없습니다. MVC의 판매 포인트는 다음과 같습니다.

  1. 단위 (테스트)
  2. 디자인 (뷰)과 로직 (컨트롤러 + 모델)을 분리
  3. 뷰 스테이트가없고 요소 ID 관리 개선
  4. RESTful URL 등 ...

그러나 코드 숨김을 사용하여 웹 양식을 사용하면 테마, 스킨 및 리소스는 이미 디자인과 논리를 분리하는 데 완벽합니다.

Viewstate : 클라이언트 ID 관리가 ASP.NET 4.0에서 제공됩니다. 단위 테스트에만 관심이 있지만 단위 테스트는 웹 양식에서 ASP.NET MVC로 전환 해야하는 이유가 충분하지 않습니다.

어쩌면 내가 말할 수 있습니다 : ASP.NET MVC는 나쁘지 않지만 webform은 이미 충분합니다.

Preview 3가 나온 이후로 MVC를 사용해 왔으며 여전히 팀 개발 영역에서 상당히 도움이되는 어려움이 있습니다. 3 명의 사람들이 하나의 웹폼 페이지에서 작업하도록하세요. 그러면 벽에 머리를 두드리는 개념을 이해할 수 있습니다. 뷰 페이지의 디자인 요소와 상주 Linq 신을 이해하는 개발자와 함께 모델을 작동시키는 동안 컨트롤러에서 모든 것을 하나로 모을 수 있습니다. 나는 관심의 분리가 매우 쉬운 영역에서 결코 발전 할 수 없었습니다.

ASP.Net MVC의 가장 큰 판매 지점 -StackOverflow는 MVC 스택에서 실행됩니다.

그 말은 ... 귀하의 코드는 일반적으로보기 페이지에서하는 것보다 훨씬 더 예쁘습니다. 또한 내가 일하는 사람 중 하나가 HTML 도우미를 태그 라이브러리에 래핑하는 작업을하고 있습니다. <% = Html.RandomFunctionHere () %> 대신 다음과 같이 작동합니다

<hh : 무작위 기능 />

MVC 팀이 더 나은 작업을 수행 할 것이라고 확신하기 때문에 어느 시점에서 MVC 팀이 접근하기를 바랍니다.

Facade Pattern을 사용하여 표시해야하는 모든 데이터에 대한 모든 논리를 래핑 한 다음 뷰에서 일반으로 사용하고 더 이상 스파게티 코드를 사용하지 마십시오. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

도움이 더 필요한 경우 cgardner2020@gmail.com

ASP.NET MVC 구현은 끔찍합니다. 제품이 suck니다. 나는 그것의 몇 가지 데모를 보았고 나는 MSFT를 부끄럽게 생각한다 ... 나는 그것을 쓴 사람들이 나보다 똑똑하다고 확신하지만 Model-View-Controller가 무엇인지 모르는 것처럼 .

MVC를 구현하려는 사람은 MSFT에서 새로운 것을 시도하는 사람뿐입니다. 내가 본 데모에서 발표자는 사과를했습니다 ...

나는 MSFT의 열렬한 팬이지만 MVC 구현을 방해 할 이유가 없다고 말해야합니다. 웹 양식을 사용하거나 웹 개발을 위해 jquery를 사용하십시오.이 가증을 선택하지 마십시오.

편집하다:

Model-View-Controller 아키텍처 디자인 패턴의 목적은 비즈니스 규칙과 도메인을 프레젠테이션에서 분리하는 것입니다. 구현 한 모든 Web Forms 프로젝트에서 패턴을 성공적으로 사용했습니다. ASP.NET MVC 제품은 실제 건축 디자인 패턴에 적합하지 않습니다.

참고 URL : https://stackoverflow.com/questions/390693/does-anyone-beside-me-just-not-get-asp-net-mvc

반응형

'IT story' 카테고리의 다른 글

SwipeRefreshLayout setRefreshing ()이 처음에 표시기를 표시하지 않음  (0) 2020.06.20
select2 입력의 너비를 설정하십시오 (Angular-ui 지시문을 통해)  (0) 2020.06.20
Android YouTube 앱 비디오 의도 재생  (0) 2020.06.20
ViewPager의 일부로 ListFragment의 데이터 업데이트  (0) 2020.06.20
Windows 배치 파일에서 팝업 / 메시지 상자 표시  (0) 2020.06.20

'IT story'의 다른글

  • 현재글내 옆에 아무도 ASP.NET MVC를 얻지 못합니까?

관련글

댓글

티스토리툴바