Có ai bên cạnh tôi chỉ KHÔNG nhận được ASP.NET MVC? [đóng cửa]

Tôi đã loay hoay với ASP.NET MVC kể từ CTP và tôi thích rất nhiều thứ họ đã làm, nhưng có những thứ tôi không nhận được.

Ví dụ: tôi đã tải xuống beta1 và tôi sẽ kết hợp một trang web cá nhân / sơ yếu lý lịch / blog với nó. Đây là đoạn trích từ chế độ xem 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> <%
        }
    %>

Kinh tởm (Cũng lưu ý rằng HTML có HTML giữ chỗ tạm thời, tôi sẽ tạo một thiết kế thực tế khi chức năng đang hoạt động) .

Tôi có làm điều gì sai? Bởi vì tôi đã trải qua nhiều ngày đen tối trong ASP cổ điển, và món súp thẻ này nhắc nhở tôi mạnh mẽ về nó.

Mọi người giảng về cách bạn có thể làm HTML sạch hơn. Đoán xem, cái gì? 1% tất cả mọi người nhìn vào HTML xuất ra. Đối với tôi, tôi không quan tâm nếu Webforms làm rối tung sự thụt lề của tôi trong HTML được hiển thị, miễn là tôi có mã dễ duy trì ... Điều này không phải!

Vì vậy, hãy chuyển đổi tôi, một anh chàng webforms chết cứng, tại sao tôi nên từ bỏ các trang ASPX được hình thành độc đáo của mình cho việc này?

Chỉnh sửa: Đã in đậm dòng "temp Html / css" để mọi người sẽ hiểu về nó.

So với Web Forms, MVC đồng thời là một cách tiếp cận cấp thấp hơn để tạo HTML với sự kiểm soát lớn hơn đối với đầu ra của trang và một cách tiếp cận dựa trên kiến ​​trúc, ở cấp độ cao hơn. Hãy để tôi chụp Web Forms và MVC và chỉ ra lý do tại sao tôi nghĩ rằng sự so sánh đó ưu tiên các Biểu mẫu Web trong nhiều tình huống - miễn là bạn không rơi vào một số bẫy Web Forms cổ điển.

Biểu mẫu web

Trong mô hình Web Forms, các trang của bạn tương ứng trực tiếp với yêu cầu trang từ trình duyệt. Do đó, nếu bạn đang hướng người dùng đến danh sách Sách, bạn có thể sẽ có một trang ở đâu đó có tên là "Booklist.aspx" mà bạn sẽ hướng dẫn anh ấy. Trong trang đó, bạn sẽ phải cung cấp mọi thứ cần thiết để hiển thị danh sách đó. Điều này bao gồm mã để lấy dữ liệu, áp dụng bất kỳ logic nghiệp vụ nào và hiển thị kết quả. Nếu có bất kỳ logic kiến ​​trúc hoặc định tuyến nào ảnh hưởng đến trang, bạn cũng sẽ phải viết mã logic kiến ​​trúc trên trang. Phát triển biểu mẫu web tốt thường liên quan đến việc phát triển một tập hợp các lớp hỗ trợ trong một DLL riêng biệt (có thể kiểm tra đơn vị). Các lớp này sẽ xử lý logic nghiệp vụ, truy cập dữ liệu và các quyết định kiến ​​trúc / định tuyến.

MVC

MVC có một cái nhìn "kiến trúc" hơn về phát triển ứng dụng web: cung cấp một giàn giáo được tiêu chuẩn hóa để xây dựng. Nó cũng cung cấp các công cụ để tự động tạo các lớp mô hình, khung nhìn và trình điều khiển trong kiến ​​trúc đã thiết lập. Ví dụ: trong cả Ruby on Rails (chỉ "Rails" từ đây trở đi) và ASP.NET MVC bạn sẽ luôn bắt đầu với cấu trúc thư mục phản ánh mô hình tổng thể của kiến ​​trúc ứng dụng web. Để thêm chế độ xem, mô hình và bộ điều khiển, bạn sẽ sử dụng một lệnh như "Rails script / tạo scaffold {modelname}" (ASP.NET MVC cung cấp các lệnh tương tự trong IDE). Trong lớp trình điều khiển kết quả, sẽ có các phương thức ("Hành động") cho Index (danh sách hiển thị), Hiển thị, Mới và Chỉnh sửa và Hủy bỏ (ít nhất là trong Rails, MVC tương tự). Theo mặc định, những "

Bố cục của các thư mục và tập tin có ý nghĩa trong MVC. Ví dụ: trong ASP.NET MVC, phương thức Index cho đối tượng "Sách" có thể sẽ chỉ có một dòng: "Return View ();" Thông qua sự kỳ diệu của MVC, điều này sẽ gửi mô hình Sách đến trang "/View/Books/Index.aspx" nơi bạn sẽ tìm thấy mã để hiển thị Sách. Cách tiếp cận của Rails tương tự mặc dù logic rõ ràng hơn một chút và ít "ma thuật" hơn. Một Xem trang trong một ứng dụng MVC là thường đơn giản hơn so với một trang Web Forms bởi vì họ không phải lo lắng nhiều về định tuyến, logic kinh doanh hoặc xử lý dữ liệu.

So sánh

Những lợi thế của MVC xoay quanh việc phân tách rõ ràng các mối quan tâm và một mô hình HTML / CSS / AJAX / Javascript tập trung hơn, sạch hơn để tạo đầu ra của bạn. Điều này giúp tăng cường khả năng kiểm tra, cung cấp một thiết kế chuẩn hơn và mở ra cơ hội cho loại trang web "Web 2.0" hơn.

Tuy nhiên, có một số nhược điểm đáng kể là tốt.

Đầu tiên, trong khi thật dễ dàng để có được một trang web demo, mô hình kiến ​​trúc tổng thể có một đường cong học tập đáng kể. Khi họ nói "Quy ước về cấu hình" nghe có vẻ tốt - cho đến khi bạn nhận ra rằng bạn có giá trị của một cuốn sách để học. Hơn nữa, thường là một chút điên rồ để tìm hiểu những gì đang xảy ra bởi vì bạn đang dựa vào ma thuật hơn là các cuộc gọi rõ ràng. Ví dụ: "Chế độ xem trả về ();" gọi ở trên? Cuộc gọi chính xác có thể được tìm thấy trong các Hành động khác nhưng chúng đi đến những nơi khác nhau. Nếu bạn hiểu quy ước MVCsau đó bạn biết tại sao điều này được thực hiện. Tuy nhiên, nó chắc chắn không đủ điều kiện làm ví dụ về cách đặt tên tốt hoặc mã dễ hiểu và các nhà phát triển mới khó nhận hơn so với Web Forms (đây không chỉ là ý kiến: Tôi đã có một thực tập mùa hè tìm hiểu Web Forms vào năm ngoái và MVC năm nay và sự khác biệt về năng suất đã được phát âm - ủng hộ Biểu mẫu web). BTW, Rails tốt hơn một chút về vấn đề này mặc dù Ruby on Rails có các phương thức được đặt tên động mà cũng có một số cách sử dụng nghiêm túc.

Thứ hai, MVC mặc nhiên cho rằng bạn đang xây dựng một trang web kiểu CRUD cổ điển. Các quyết định kiến ​​trúc và đặc biệt là các trình tạo mã đều được xây dựng để hỗ trợ loại ứng dụng web này. Nếu bạn đang xây dựng một ứng dụng CRUD và muốn áp dụng một kiến ​​trúc đã được chứng minh (hoặc đơn giản là không thích thiết kế kiến ​​trúc), thì có lẽ bạn nên xem xét MVC. Tuy nhiên, nếu bạn sẽ làm nhiều hơn CRUD và / hoặc bạn có năng lực hợp lý với kiến ​​trúc thì MVC có thể cảm thấy giống như một chiếc áo khoác cho đến khi bạn thực sự làm chủ mô hình định tuyến cơ bản (phức tạp hơn đáng kể so với định tuyến đơn giản trong ứng dụng WebForms). Ngay cả sau đó, tôi đã cảm thấy như tôi luôn chiến đấu với người mẫu và lo lắng về kết quả không mong muốn.

Thứ ba, nếu bạn không quan tâm đến Linq (vì bạn sợ rằng Linq-to-SQL sẽ biến mất hoặc vì bạn thấy Linq-to-Entity bị sản xuất quá mức và được cung cấp năng lượng) thì bạn cũng không muốn để đi theo con đường này vì các công cụ giàn giáo ASP.NET MVC được xây dựng xung quanh Linq (đây là kẻ giết tôi). Mô hình dữ liệu của Rails cũng khá vụng về so với những gì bạn có thể đạt được nếu bạn có kinh nghiệm về SQL (và đặc biệt là nếu bạn thành thạo TSQL và các thủ tục được lưu trữ!).

Thứ tư, những người đề xuất MVC thường chỉ ra rằng các khung nhìn MVC gần gũi hơn với mô hình HTML / CSS / AJAX của web. Ví dụ: "Trình trợ giúp HTML" - các lệnh gọi mã nhỏ trong trang vew của bạn hoán đổi nội dung và đặt nó vào các điều khiển HTML - dễ dàng tích hợp với Javascript hơn các điều khiển Web Forms. Tuy nhiên, ASP.NET 4.0 giới thiệu khả năng đặt tên cho các điều khiển của bạn và do đó phần lớn loại bỏ lợi thế này.

Thứ năm, những người theo chủ nghĩa thuần túy MVC thường chế nhạo Viewstate. Trong một số trường hợp, họ có quyền làm như vậy. Tuy nhiên, Viewstate cũng có thể là một công cụ tuyệt vời và mang lại lợi ích cho năng suất. Bằng cách so sánh, xử lý ViewState là nhiều dễ dàng hơn cố gắng để tích hợp các điều khiển web của bên thứ ba trong một ứng dụng MVC. Mặc dù tích hợp điều khiển có thể trở nên dễ dàng hơn đối với MVC, nhưng tất cả những nỗ lực hiện tại mà tôi thấy phải chịu là cần phải xây dựng mã (hơi khó hiểu) để liên kết các điều khiển này trở lại lớp Trình điều khiển của khung nhìn (nghĩa là - để hoạt động xung quanh mô hình MVC ).

Kết luận

Tôi thích phát triển MVC theo nhiều cách (mặc dù tôi thích Rails hơn ASP.NET MVC bởi một cú sút xa). Tôi cũng nghĩ rằng điều quan trọng là chúng ta không rơi vào cái bẫy nghĩ rằng ASP.NET MVC là một "mô hình chống" của ASP.NET Web Forms. Họ khác nhau nhưng không hoàn toàn xa lạ và chắc chắn có chỗ cho cả hai.

Tuy nhiên, tôi thích phát triển Biểu mẫu Web vì, đối với hầu hết các tác vụ , đơn giản là hoàn thành công việc dễ dàng hơn (ngoại trừ việc tạo ra một tập hợp các biểu mẫu CRUD). MVC dường như cũng bị ảnh hưởng, ở một mức độ nào đó, từ sự vượt quá lý thuyết. Thật vậy, hãy nhìn vào nhiều câu hỏi được hỏi ở đây trên SO bởi những người biết ASP.NET định hướng trang nhưng những người đang thử MVC. Không có ngoại lệ, có rất nhiều nghiến răng khi các nhà phát triển thấy rằng họ không thể thực hiện các nhiệm vụ cơ bản mà không phải nhảy qua vòng hoặc chịu đựng một đường cong học tập lớn. Đây là điều làm cho Web Forms vượt trội hơn so với MVC trong cuốn sách của tôi: MVC khiến bạn phải trả giá bằng thế giới thực để có thêm một chút khả năng kiểm tra hoặc tệ hơn nữa là đơn giản được xem là tuyệt vời vì bạn đang sử dụngcông nghệ mới nhất.

Cập nhật: Tôi đã bị chỉ trích rất nhiều trong phần bình luận - một số trong đó khá công bằng. Vì vậy, tôi đã dành vài tháng để học Rails và ASP.NET MVC chỉ để đảm bảo rằng tôi đã không thực sự bỏ lỡ điều lớn lao tiếp theo! Tất nhiên, nó cũng giúp đảm bảo rằng tôi cung cấp một câu trả lời cân bằng và phù hợp cho câu hỏi. Bạn nên biết rằng phản hồi trên là một bản viết lại chính của câu trả lời ban đầu của tôi trong trường hợp các bình luận dường như không đồng bộ.

Trong khi tôi đang tìm hiểu kỹ hơn về MVC, tôi nghĩ, trong một thời gian ngắn, tôi sẽ kết thúc với một mea culpa lớn. Cuối cùng tôi đã kết luận rằng, trong khi tôi nghĩ rằng chúng ta cần dành nhiều năng lượng hơn cho kiến ​​trúc và khả năng kiểm tra của Web Forms, thì MVC thực sự không trả lời cuộc gọi cho tôi. Vì vậy, một "lời cảm ơn" nồng nhiệt đến những người cung cấp những lời phê bình thông minh cho câu trả lời ban đầu của tôi.

Đối với những người coi đây là một trận chiến tôn giáo và những người không ngừng chế tạo lũ lụt, tôi không hiểu tại sao bạn lại bận tâm (hơn 20 phiếu bầu trong vài giây nhiều lần chắc chắn là không bình thường). Nếu bạn đang đọc câu trả lời này và tự hỏi liệu có gì đó thực sự "sai" về câu trả lời của tôi cho rằng điểm số thấp hơn nhiều so với một số câu trả lời khác, hãy yên tâm rằng nó nói nhiều hơn về một số người không đồng ý với ý nghĩa chung về cộng đồng (nói chung, cái này đã được nâng cấp hơn 100 lần).

Thực tế là nhiều nhà phát triển không quan tâm đến MVC và thực sự, đây không phải là một quan điểm thiểu số (ngay cả trong MS như các blog dường như chỉ ra).

MVC cung cấp cho bạn nhiều quyền kiểm soát hơn đối với đầu ra của bạn và với sự kiểm soát đó có nguy cơ cao hơn khi viết HTML được thiết kế kém, súp thẻ, v.v ...

Nhưng đồng thời, bạn có một số tùy chọn mới mà bạn chưa có trước đây ...

1. Kiểm soát nhiều hơn trên trang và các yếu tố trong trang
2. Ít "rác" hơn trong đầu ra của bạn, như ViewState hoặc ID quá dài trên các thành phần (đừng hiểu sai ý tôi, tôi thích ViewState)
3. Khả năng tốt hơn để lập trình phía máy khách với Javascript (Ứng dụng Web 2.0 có ai không?)
4. Không chỉ MVC, mà JsonResult cũng rất ...

Bây giờ không có nghĩa là bạn không thể thực hiện bất kỳ điều nào trong số này với WebForms, nhưng MVC giúp việc này dễ dàng hơn.

Tôi vẫn sử dụng WebForms khi tôi cần nhanh chóng tạo một ứng dụng web vì tôi có thể tận dụng các điều khiển máy chủ, v.v. WebForms ẩn tất cả các chi tiết của thẻ đầu vào và gửi nút.

Cả WebForms và MVC đều có khả năng dọn rác tuyệt đối nếu bạn bất cẩn. Như mọi khi, lập kế hoạch cẩn thận và thiết kế chu đáo sẽ dẫn đến một ứng dụng chất lượng, bất kể đó là MVC hay WebForms.

[Cập nhật]

Nếu đó là bất kỳ sự an ủi nào, MVC chỉ là một công nghệ mới, đang phát triển từ Microsoft. Đã có nhiều bài đăng rằng WebForms sẽ không chỉ tồn tại mà còn tiếp tục được phát triển cho ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... và như thế...

Đối với những người quan tâm về lộ trình mà MVC đang thực hiện, tôi khuyên bạn nên cung cấp cho "các chàng" phản hồi của bạn. Họ dường như đang lắng nghe cho đến nay!

Hầu hết các phản đối đối với ASP.NET MVC dường như tập trung vào các khung nhìn, đây là một trong những bit "tùy chọn" và mô-đun nhất trong kiến ​​trúc. NVelocity , NHaml , Spark , XSLT và các công cụ xem khác có thể dễ dàng hoán đổi (và mọi thứ trở nên dễ dàng hơn với mỗi bản phát hành). Nhiều trong số đó có NHIỀU cú pháp ngắn gọn hơn để thực hiện logic và định dạng trình bày, trong khi vẫn kiểm soát hoàn toàn HTML được phát ra.

Ngoài ra, gần như mọi lời chỉ trích dường như đều được gắn thẻ <%%> trong chế độ xem mặc định và mức độ "xấu xí" của nó. Ý kiến ​​đó thường bắt nguồn từ việc sử dụng phương pháp WebForms, nó chỉ chuyển phần lớn sự xấu xí cổ điển của ASP vào tệp mã phía sau.

Ngay cả khi không thực hiện mã "sai", bạn vẫn có những thứ như OnItemDataBound trong Repeater, điều này cũng xấu về mặt thẩm mỹ, nếu chỉ theo một cách khác, hơn là "canh canh thẻ". Một vòng lặp foreach có thể dễ đọc hơn nhiều, ngay cả với việc nhúng biến trong đầu ra của vòng lặp đó, đặc biệt nếu bạn đến với MVC từ các công nghệ non-ASP.NET khác. Google-fu cần ít hiểu biết về vòng lặp foreach hơn là tìm ra cách sửa đổi một trường trong bộ lặp của bạn là gây rối với OnItemDataBound (và tổ chuột kiểm tra xem đó có phải là yếu tố đúng không.

Vấn đề lớn nhất với "spaghetti" được điều khiển bằng thẻ tag là nhiều hơn về các thứ như kết nối cơ sở dữ liệu ngay giữa HTML.

Rằng điều đó đã xảy ra khi sử dụng <%%> chỉ là mối tương quan với bản chất spaghetti của ASP cổ điển, chứ không phải quan hệ nhân quả. Nếu bạn giữ logic xem của mình thành HTML / CSS / Javascript và logic tối thiểu cần thiết để trình bày , phần còn lại là cú pháp.

Khi so sánh một chút chức năng nhất định với WebForms, hãy đảm bảo bao gồm tất cả C # do nhà thiết kế tạo và C # mã phía sau cùng với mã .aspx để chắc chắn rằng giải pháp MVC thực sự không đơn giản hơn nhiều .

Khi kết hợp với việc sử dụng hợp lý các chế độ xem một phần cho các bit trình bày logic lặp lại, nó thực sự có thể tốt và thanh lịch.

Cá nhân, tôi mong muốn phần lớn nội dung hướng dẫn sớm tập trung nhiều vào phần cuối của vấn đề này hơn là chỉ dựa vào kiểm soát, đảo ngược kiểm soát, v.v. Mặc dù những thứ khác là thứ mà các chuyên gia phản đối để phản đối "súp canh".

Bất kể, đây là một nền tảng vẫn đang trong giai đoạn thử nghiệm. Mặc dù vậy, nó sẽ khiến WAY triển khai nhiều hơn và các nhà phát triển không phải là Microsoft xây dựng công cụ thực tế với nó hơn hầu hết công nghệ Microsoft-beta. Như vậy, buzz có xu hướng làm cho nó có vẻ như xa hơn so với cơ sở hạ tầng xung quanh nó (tài liệu, mẫu hướng dẫn, v.v.). Nó thực sự có thể sử dụng được tại thời điểm này chỉ khuếch đại hiệu ứng đó.

<% 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>
<% } %>

Bạn có thể tạo một bài đăng khác hỏi làm thế nào để làm điều này mà không bao gồm CSS nhúng.

LƯU Ý: ViewData.Model trở thành Model trong phiên bản tiếp theo.

Và với sự trợ giúp của người dùng kiểm soát, điều này sẽ trở thành

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

trong đó PagerData được khởi tạo thông qua một hàm tạo ẩn danh trong trình xử lý hành động.

chỉnh sửa: Tôi tò mò việc triển khai WebForm của bạn sẽ như thế nào đối với vấn đề này.

Tôi không chắc chắn tại thời điểm nào mọi người ngừng quan tâm đến mã của họ.

HTML là màn hình hiển thị công khai nhất cho công việc của bạn, có rất nhiều nhà phát triển sử dụng notepad, notepad ++ và các trình soạn thảo văn bản đơn giản khác để xây dựng nhiều trang web.

MVC là về việc lấy lại quyền kiểm soát từ các biểu mẫu web, làm việc trong môi trường không trạng thái và triển khai mẫu thiết kế Model View Controller mà không cần tất cả các công việc bổ sung thường diễn ra trong quá trình thực hiện mẫu này.

Nếu bạn muốn kiểm soát, làm sạch mã và sử dụng các mẫu thiết kế MVC, thì đây là dành cho bạn, nếu bạn không thích làm việc với đánh dấu, đừng quan tâm đến việc đánh dấu của bạn bị sai, hãy sử dụng Biểu mẫu web của ASP.Net.

Nếu bạn không thích một trong hai, bạn chắc chắn sẽ làm gần như nhiều công việc trong đánh dấu.

EDIT Tôi cũng nên nói rằng Web Forms và MVC có vị trí của chúng, tôi không có cách nào nói rằng cái này tốt hơn cái kia, chỉ có mỗi MVC có sức mạnh để lấy lại quyền kiểm soát đánh dấu.

Tôi nghĩ rằng bạn đang thiếu một số điều. Đầu tiên, không cần Phản hồi. Viết, bạn có thể sử dụng các <%= %>thẻ. Thứ hai, bạn có thể viết các phần mở rộng HtmlHelper của riêng bạn để thực hiện các hành động phổ biến. Thứ ba, một chút định dạng giúp rất nhiều. Thứ tư, tất cả những điều này có thể sẽ bị kẹt trong điều khiển người dùng để được chia sẻ giữa một số chế độ xem khác nhau và do đó, đánh dấu tổng thể trong chế độ xem chính là sạch hơn.

Tôi sẽ cấp cho bạn rằng việc đánh dấu vẫn không gọn gàng như mong muốn, nhưng nó có thể được làm sạch đáng kể thông qua việc sử dụng một số biến tạm thời.

Bây giờ, điều đó không tệ lắm và sẽ còn tốt hơn nữa nếu tôi không phải định dạng nó cho 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>

  <% } %>

Vấn đề lớn với MVC là nó là một khung khái niệm đã có từ lâu và nó đã chứng tỏ là một cách hiệu quả, mạnh mẽ để xây dựng cả ứng dụng web và ứng dụng máy trạm có quy mô theo chiều ngang và chiều dọc. Nó đi trực tiếp trở lại Alto và Smalltalk. Microsoft đến dự tiệc muộn. Những gì chúng ta có bây giờ với ASP.NET MVC thực sự rất sơ khai, bởi vì có quá nhiều thứ bắt kịp để làm; nhưng chết tiệt, họ đang tung ra các bản phát hành mới nhanh và dữ dội.

Thỏa thuận lớn với Ruby on Rails là gì? Rails là MVC. Các nhà phát triển đã chuyển đổi bởi vì, bằng lời nói, nó trở thành cách để các lập trình viên làm việc hiệu quả.

Đó là một thỏa thuận lớn; MVC và sự chứng thực ngầm của jQuery là điểm bùng phát để Microsoft chấp nhận rằng trung lập nền tảng là rất quan trọng. Và điều trung lập về nó, là không giống như Web Forms, Microsoft không thể khóa bạn về mặt khái niệm. Bạn có thể lấy tất cả mã C # của mình và thực hiện lại hoàn toàn bằng ngôn ngữ khác (giả sử PHP hoặc java - bạn đặt tên cho nó) bởi vì đó là khái niệm MVC có thể mang theo, không phải là mã. (Và nghĩ rằng nó có thể lớn đến mức nào mà bạn có thể lấy thiết kế của mình và triển khai nó như một ứng dụng máy trạm với ít thay đổi mã và không thay đổi thiết kế. Hãy thử điều đó với Web Forms.)

Microsoft đã quyết định rằng Web Forms sẽ không phải là VB6 tiếp theo.

Xin hãy xem bài viết của Rob Conery Tôi sẽ nói: Bạn nên học MVC

Hai ưu điểm chính của khung ASP.NET MVC so với các biểu mẫu web là:

1. Testability - Giao diện và các sự kiện trong các hình thức web là gần như không thể kiểm tra. Với ASP.NET MVC, các hành động kiểm soát đơn vị kiểm tra đơn vị và các khung nhìn mà chúng hiển thị rất dễ dàng. Điều này đi kèm với một chi phí trong chi phí phát triển trước, nhưng các nghiên cứu đã chỉ ra rằng điều này sẽ mang lại kết quả lâu dài khi đến lúc phải cấu trúc lại và duy trì ứng dụng.
2. Kiểm soát tốt hơn đối với HTML được hiển thị - Bạn nói rằng bạn không quan tâm đến HTML được hiển thị vì không ai nhìn vào HTML. Đó là một khiếu nại hợp lệ nếu đó là lý do duy nhất để có định dạng HTML chính xác. Có rất nhiều lý do để muốn HTML được định dạng chính xác bao gồm: SEO, khả năng sử dụng bộ chọn id thường xuyên hơn (trong css và javascript), dấu chân trang nhỏ hơn do thiếu viewstate và id dài lố bịch (ctl00_etcetcetc).

Bây giờ, những lý do này không thực sự làm cho ASP.NET MVC trở nên tốt hơn hoặc tồi tệ hơn các biểu mẫu web theo cách thức đen trắng. ASP.NET MVC có điểm mạnh và điểm yếu, giống như các hình thức web. Tuy nhiên, phần lớn những lời phàn nàn về ASP.NET MVC dường như xuất phát từ sự thiếu hiểu biết về cách sử dụng nó hơn là những sai sót thực tế trong khung. Lý do mã của bạn không cảm thấy đúng hoặc nhìn đúng có thể là do bạn có nhiều năm kinh nghiệm biểu mẫu web trong vành đai của mình và chỉ 1-2 tháng trải nghiệm ASP.NET MVC.

Vấn đề ở đây không phải là nhiều đến mức ASP.NET MVC đá hay tệ, nó mới và có rất ít thỏa thuận về cách sử dụng nó một cách chính xác. ASP.NET MVC cung cấp khả năng kiểm soát chi tiết hơn nhiều đối với những gì xảy ra trong ứng dụng của bạn. Điều đó có thể làm cho một số nhiệm vụ dễ dàng hơn hoặc khó hơn tùy thuộc vào cách bạn tiếp cận chúng.

Này, tôi cũng đang vật lộn với việc chuyển sang MVC. Tôi hoàn toàn không phải là một fan hâm mộ của kết xuất đồ họa cổ điển và ASP nhắc nhở tôi rất nhiều về những ngày đó. Tuy nhiên, tôi càng sử dụng MVC, nó càng phát triển trong tôi. Tôi là một anh chàng webforms (như nhiều người) và đã dành nhiều năm qua để làm quen với các datagrids, v.v ... Với MVC bị lấy đi. Các lớp trợ giúp HTML là câu trả lời.

Gần đây tôi đã dành 2 ngày để cố gắng tìm ra cách tốt nhất để thêm phân trang vào một "lưới" trong MVC. Bây giờ, với các biểu mẫu web tôi có thể xóa nó ngay lập tức. Nhưng tôi sẽ nói điều này ... một khi tôi đã có các lớp trình trợ giúp phân trang được xây dựng cho MVC, nó trở nên cực kỳ đơn giản để thực hiện. Đối với tôi, thậm chí còn dễ dàng hơn các biểu mẫu web.

Điều đó đang được nói, tôi nghĩ rằng MVC sẽ thân thiện với nhà phát triển hơn nhiều khi có một bộ Trình trợ giúp HTML nhất quán ngoài kia. Tôi nghĩ rằng chúng ta sẽ bắt đầu thấy một tấn các lớp trợ giúp HTML xuất hiện trên web trong tương lai gần.

Thật buồn cười vì đó là những gì tôi đã nói khi lần đầu tiên nhìn thấy các biểu mẫu web.

Tôi sẽ thừa nhận rằng tôi chưa nhận được asp.net MVC. Tôi đang cố gắng sử dụng nó trong một dự án phụ tôi đang làm nhưng nó sẽ khá chậm.

Bên cạnh việc không thể làm những việc rất dễ thực hiện trong các biểu mẫu web, tôi nhận thấy súp tag. Nó thực sự dường như có một bước lùi từ quan điểm đó. Tôi tiếp tục hy vọng rằng khi tôi học nó sẽ trở nên tốt hơn.

Cho đến nay tôi đã nhận thấy rằng lý do hàng đầu để sử dụng MVC là để giành quyền kiểm soát hoàn toàn đối với HTML của bạn. Tôi cũng đọc rằng asp.net MVC có thể phục vụ nhiều trang nhanh hơn các biểu mẫu web và có thể liên quan đến điều này, kích thước trang cá nhân nhỏ hơn một trang biểu mẫu web trung bình.

Tôi thực sự không quan tâm HTML của mình trông như thế nào miễn là nó hoạt động trong các trình duyệt chính, nhưng tôi quan tâm đến việc trang của tôi tải nhanh như thế nào và chúng chiếm bao nhiêu băng thông.

Mặc dù tôi hoàn toàn đồng ý rằng đó là đánh dấu xấu xí, tôi nghĩ rằng việc sử dụng cú pháp khung nhìn xấu xí để loại bỏ ASP.NET MVC nói chung là không công bằng. Cú pháp xem đã nhận được sự chú ý ít nhất từ ​​Microsoft và tôi hoàn toàn mong đợi điều gì đó sẽ được thực hiện sớm.

Các câu trả lời khác đã thảo luận về lợi ích của MVC nói chung, vì vậy tôi sẽ tập trung vào cú pháp xem:

Việc khuyến khích sử dụng Html.ActionLink và các phương pháp khác tạo HTML là một bước đi sai hướng. Điều này đánh vào các điều khiển máy chủ, và, với tôi, đang giải quyết một vấn đề không tồn tại. Nếu chúng ta sẽ tạo các thẻ từ mã, vậy thì tại sao lại phải sử dụng HTML? Chúng tôi chỉ có thể sử dụng DOM hoặc một số mô hình khác và xây dựng nội dung của chúng tôi trong bộ điều khiển. Ok, nghe có vẻ tệ phải không? Ồ vâng, tách các mối quan tâm, đó là lý do tại sao chúng ta có một quan điểm.

Tôi nghĩ rằng hướng chính xác là làm cho cú pháp xem càng giống với HTML càng tốt. Hãy nhớ rằng, một MVC được thiết kế tốt không chỉ giúp bạn tách mã khỏi nội dung, nó sẽ cho phép bạn hợp lý hóa việc sản xuất của mình bằng cách có những người là chuyên gia về bố cục làm việc trên các khung nhìn (mặc dù họ không biết ASP.NET), và sau đó sau này với tư cách là nhà phát triển, bạn có thể bước vào và làm cho chế độ xem mockup thực sự động. Điều này chỉ có thể được thực hiện nếu cú ​​pháp khung nhìn trông rất giống HTML, để mọi người bố trí có thể sử dụng DreamWeaver hoặc bất kỳ công cụ bố cục phổ biến hiện tại nào. Bạn có thể đang xây dựng hàng tá trang web cùng một lúc và cần mở rộng quy mô theo cách này để đạt hiệu quả sản xuất. Hãy để tôi đưa ra một ví dụ về cách tôi có thể thấy chế độ xem "ngôn ngữ" hoạt động:

<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;" />

Điều này có một số lợi thế:

• trông tốt hơn
• súc tích hơn
• không có bối cảnh chuyển đổi bối cảnh vui nhộn giữa các thẻ HTML và <%%>
• các từ khóa dễ hiểu là tự giải thích (ngay cả một người không lập trình cũng có thể làm điều này - tốt cho việc song song hóa)
• càng nhiều logic chuyển trở lại vào bộ điều khiển (hoặc mô hình) càng tốt
• không tạo HTML - một lần nữa, điều này giúp người khác dễ dàng truy cập và biết nơi để tạo kiểu một cái gì đó, mà không phải loay hoay với Html. phương pháp
• mã có văn bản mẫu trong đó hiển thị khi bạn tải chế độ xem dưới dạng HTML đơn giản trong trình duyệt (một lần nữa, tốt cho người bố trí)

Vì vậy, chính xác những gì cú pháp này làm gì?

mvc: Internal = "" - bất cứ điều gì trong dấu ngoặc kép đều được đánh giá và HTML bên trong của thẻ được thay thế bằng chuỗi kết quả. (Văn bản mẫu của chúng tôi được thay thế)

mvc: outs = "" - bất cứ điều gì trong dấu ngoặc kép đều được đánh giá và HTML bên ngoài của thẻ được thay thế bằng chuỗi kết quả. (Một lần nữa, văn bản mẫu được thay thế.)

{} - cái này được sử dụng để chèn đầu ra bên trong các thuộc tính, tương tự như <% =%>

mvc: if = "" - insde the qoutes là biểu thức boolean được bỏ qua. Đóng của if là nơi thẻ HTML được đóng lại.

mvc: khác

mcv: otherif = "" - ...

mvc: thuyết minh

Bây giờ, tôi chỉ có thể nói cho chính mình ở đây:

IMO, nếu bạn là một người khó tính (bất cứ điều gì) thì chuyển đổi không dành cho bạn. Nếu bạn yêu thích WebForms, vì bạn có thể hoàn thành những gì bạn cần và đó cũng là mục tiêu của bất kỳ ai.

Webforms thực hiện tốt công việc trừu tượng hóa HTML từ nhà phát triển . Nếu đó là mục tiêu của bạn, hãy gắn bó với Web Forms. Bạn có tất cả các chức năng "nhấp và kéo" tuyệt vời đã giúp phát triển máy tính để bàn như ngày nay. Có nhiều điều khiển đi kèm (cộng với vô số điều khiển của bên thứ ba) có thể mang lại chức năng khác nhau. Bạn có thể kéo một "lưới" được liên kết trực tiếp với DataSource từ cơ sở dữ liệu của bạn; nó đi kèm với tích hợp chỉnh sửa nội tuyến, phân trang, v.v.

Hiện tại, ASP.NET MVC rất hạn chế về mặt kiểm soát của bên thứ ba. Vì vậy, một lần nữa, nếu bạn thích Phát triển ứng dụng nhanh, nơi có rất nhiều chức năng được kết nối với bạn, bạn không nên cố gắng chuyển đổi.

Với tất cả những gì đã nói, đây là nơi ASP.NET tỏa sáng: - TDD. Mã không thể kiểm tra, nuff nói.

• Tách biệt mối quan tâm. Đó là xương sống của mẫu MVC. Tôi hoàn toàn biết rằng bạn có thể thực hiện điều này trong Biểu mẫu web. Tuy nhiên, tôi thích cấu trúc áp đặt. Thật quá dễ dàng trong Web Forms để trộn thiết kế và logic. ASP.NET MVC giúp các thành viên khác nhau trong nhóm làm việc trên các phần khác nhau của ứng dụng dễ dàng hơn.

• Đến từ một nơi khác: Nền tảng của tôi là CakePHP và Ruby on Rails. Vì vậy, rõ ràng sự thiên vị của tôi nằm ở đâu. Nó chỉ đơn giản là về những gì bạn cảm thấy thoải mái.

• Học đường cong: Để mở rộng về điểm cuối cùng; Tôi ghét ý tưởng "tạo khuôn mẫu" để thay đổi chức năng của các yếu tố khác nhau. Tôi không thích thực tế là rất nhiều thiết kế đã được hoàn thành trong mã phía sau tập tin. Đó là một điều nữa để tìm hiểu, khi tôi đã quen thuộc với HTML và CSS. Nếu tôi muốn làm một cái gì đó trong một "phần tử" trên trang, tôi sẽ dán "div" hoặc "span", tát một ID trên đó và tắt đi. Trong các hình thức web tôi sẽ phải đi nghiên cứu làm thế nào để làm điều này.

• "Thiết kế" hiện tại của Web: Các thư viện Javascript như jQuery đang trở nên phổ biến hơn. Cách mà Web Forms thu thập ID của bạn chỉ khiến việc triển khai (bên ngoài Visual Studio) trở nên khó khăn hơn.

• Tách biệt nhiều hơn (Thiết kế): Vì rất nhiều thiết kế được kết nối với các điều khiển của bạn, nên sẽ rất khó để kiến ​​thức của một nhà thiết kế bên ngoài (không có Web Forms) làm việc trong dự án Web Forms. Web Forms được xây dựng để kết thúc tất cả và là tất cả.

Một lần nữa, phần lớn những lý do này xuất phát từ sự không quen thuộc của tôi với Web Forms. Một dự án Web Forms (nếu được thiết kế đúng) có thể có "hầu hết" các lợi ích của ASP.NET MVC. Nhưng đó là lời cảnh báo: "Nếu được thiết kế đúng". Và đó chỉ là điều tôi không biết cách thực hiện trong Biểu mẫu web.

Nếu bạn đang làm công việc xuất sắc trong Biểu mẫu web, bạn hiệu quả và nó hoạt động cho bạn, đó là nơi bạn nên ở lại.

Về cơ bản, hãy đánh giá nhanh cả hai (cố gắng tìm một nguồn không thiên vị [chúc may mắn]) với danh sách ưu và nhược điểm, đánh giá cái nào phù hợp với mục tiêu của bạn và chọn dựa trên đó.

Tóm lại, chọn con đường ít kháng cự nhất và có lợi nhất để đáp ứng mục tiêu của bạn. Web Forms là một khung rất trưởng thành và sẽ chỉ trở nên tốt hơn trong tương lai. ASP.NET MVC đơn giản là một giải pháp thay thế khác (để thu hút các nhà phát triển Ruby on Rails và CakePHP như tôi: P)

Các tệp Java của Java EE trông như thế này khi chúng được đề xuất lần đầu tiên - mã scriptlet xấu xí.

Sau đó, họ cung cấp các thư viện thẻ để làm cho chúng thêm thẻ HTML-ish. Vấn đề là bất cứ ai cũng có thể viết một thư viện thẻ. Một số kết quả là thảm họa, bởi vì mọi người đã nhúng rất nhiều logic (và thậm chí cả kiểu) vào các thư viện thẻ tạo HTML.

Tôi nghĩ rằng giải pháp tốt nhất là Thư viện thẻ tiêu chuẩn (JSTL). Đó là "tiêu chuẩn", thẻ HTML-ish và giúp ngăn mọi người đưa logic vào các trang.

Một lợi ích bổ sung là nó bảo tồn ranh giới giữa các nhà thiết kế và phát triển web. Các trang web tốt mà tôi thấy được thiết kế bởi những người có ý thức thẩm mỹ và thiết kế cho khả năng sử dụng. Họ bố trí các trang và CSS và chuyển chúng cho các nhà phát triển, những người thêm vào các bit dữ liệu động. Nói như một nhà phát triển thiếu những món quà này, tôi nghĩ rằng chúng tôi tặng một thứ quan trọng khi chúng tôi yêu cầu các nhà phát triển viết các trang web từ súp đến các loại hạt. Flex và Silverlight sẽ gặp phải vấn đề tương tự, vì không chắc các nhà thiết kế sẽ biết rõ về JavaScript và AJAX.

Nếu .NET có đường dẫn tương tự như JSTL, tôi khuyên họ nên xem xét nó.

Chỉ cần nghĩ rằng tôi sẽ chia sẻ mẫu này trông như thế nào với công cụ xem dao cạo mới sáng bóng được mặc định kể từ ASP .NET MVC 3.

@{ 
    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>
}

Bất kỳ vấn đề với điều đó?
Ngoài ra, bạn thực sự không nên nội tuyến các kiểu CSS của mình, phải không? Và tại sao bạn kiểm tra vô hiệu ở ba nơi thay vì chỉ hai? Một thêm divhiếm khi đau. Đây là cách tôi sẽ làm:

<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>

Tôi không thể nói chuyện trực tiếp với dự án ASP.NET MVC, nhưng nói chung, các khung MVC đã chiếm ưu thế trong phát triển ứng dụng web vì

1. Họ cung cấp một sự tách biệt chính thức giữa Hoạt động cơ sở dữ liệu, "Logic nghiệp vụ" và Trình bày

2. Chúng cung cấp đủ tính linh hoạt trong chế độ xem để cho phép các nhà phát triển điều chỉnh HTML / CSS / Javascript của họ để hoạt động trong nhiều trình duyệt và các phiên bản tương lai của các trình duyệt đó

Đây là chút cuối cùng đó là điều quan trọng. Với Webforms và các công nghệ tương tự, bạn đang dựa vào nhà cung cấp của mình để viết HTML / CSS / Javascript cho bạn. Đó là thứ mạnh mẽ, nhưng bạn không có gì đảm bảo rằng phiên bản Webforms hiện tại sẽ hoạt động với thế hệ trình duyệt web tiếp theo.

Đó là sức mạnh của quan điểm. Bạn có toàn quyền kiểm soát HTML của ứng dụng của bạn. Nhược điểm là, bạn cần phải đủ kỷ luật để giữ logic trong quan điểm của bạn ở mức tối thiểu và giữ mã mẫu đơn giản nhất có thể.

Vì vậy, đó là sự đánh đổi. Nếu Webforms hoạt động cho bạn và MVC không, thì hãy tiếp tục sử dụng Webforms

Hầu hết sự thất vọng của tôi với nó chỉ là không biết cách làm mọi thứ "đúng cách". Vì nó được phát hành dưới dạng bản xem trước, tất cả chúng ta đều có một chút thời gian để xem xét mọi thứ, nhưng chúng đã thay đổi khá nhiều. Lúc đầu, tôi thực sự thất vọng nhưng khung có vẻ đủ khả thi để cho phép tôi tạo giao diện người dùng cực kỳ phức tạp (đọc: Javascript) khá nhanh. Tôi hiểu rằng bạn có thể làm điều này với Webforms như tôi đã làm trước đây nhưng đó là một nỗi đau rất lớn ở mông khi cố gắng để mọi thứ được hiển thị chính xác. Nhiều lần tôi sẽ sử dụng một bộ lặp để kiểm soát đầu ra chính xác và cuối cùng cũng sẽ có rất nhiều mớ hỗn độn spaghetti mà bạn có ở trên.

Trong nỗ lực để không gặp phải tình trạng lộn xộn tương tự, tôi đã sử dụng kết hợp có tên miền, các lớp dịch vụ và dto để chuyển sang chế độ xem. Đặt nó cùng với tia lửa, một công cụ xem và nó thực sự tốt đẹp. Phải mất một chút để thiết lập nhưng một khi bạn thực hiện được, tôi đã thấy một bước tiến lớn về sự phức tạp của các ứng dụng của mình một cách trực quan, nhưng thật đơn giản để làm mã thông minh.

Tôi có thể sẽ không làm chính xác như thế này nhưng đây là ví dụ của bạn:

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

Điều đó khá dễ bảo trì, có thể kiểm chứng và có vị rất ngon trong món súp mã của tôi.

Điều đáng nói là mã sạch là thực sự có thể, nhưng đó là một sự thay đổi lớn từ cách chúng ta đang làm. Tôi không nghĩ rằng tất cả mọi người mò mẫm nó mặc dù. Tôi biết tôi vẫn đang tìm ra nó ...

Cuốn sách được xuất bản gần đây của Steve Sanderson 'Pro ASP.NET MVC' [1] [2] từ Apress gợi ý một cách khác - tạo ra một phần mở rộng HtmlHelper tùy chỉnh. Mẫu của anh ấy (từ Chương 4 trên trang 110) sử dụng ví dụ về danh sách phân trang, nhưng nó có thể dễ dàng được điều chỉnh cho tình huống của bạn.

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();
}

Bạn sẽ gọi nó trong chế độ xem của bạn với mã như thế này:

<%= 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.vn/books?id=Xb3a1xTSfZgC

Tôi đã hy vọng nhìn thấy một bài đăng từ Phil Haack, nhưng nó không ở đây vì vậy tôi chỉ cần cắt và dán nó từ http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -tearn-mvc / trong phần bình luận

Haacked - 23 tháng 4 năm 2009 - Rob, bạn là một kẻ bạo loạn! :) Tôi thấy buồn cười khi mọi người viết mã spaghetti trong MVC và sau đó nói "nhìn! Spaghetti!" Này, tôi cũng có thể viết mã spaghetti trong Biểu mẫu web! Tôi có thể viết nó trong rails, PHP, Java, Javascript, nhưng không phải Lisp. Nhưng chỉ bởi vì tôi chưa thể viết bất cứ điều gì trong Lisp. Và khi tôi viết mã spaghetti, tôi không nhìn vào đĩa của mình, mong chờ được thấy mì ống. Điểm mọi người thường đưa ra khi so sánh nó với ASP cổ điển là với những người cổ điển của ASP có xu hướng trộn lẫn các mối quan tâm. Các trang sẽ có logic xem với xử lý đầu vào của người dùng được trộn lẫn với mã mô hình và logic nghiệp vụ tất cả được trộn lẫn trong một. Đó là những gì spaghetti đã về! Trộn tất cả các mối quan tâm trong một mớ hỗn độn lớn. Với ASP.NET MVC, nếu bạn làm theo mẫu, bạn sẽ ít làm điều đó hơn. Vâng, bạn vẫn có thể có một chút mã trong chế độ xem của mình, nhưng hy vọng đó là tất cả mã xem. Mẫu khuyến khích bạn không đặt mã tương tác người dùng của mình vào đó. Đặt nó trong bộ điều khiển. Đặt mã mô hình của bạn trong một lớp mô hình. Đó Không có mì spaghetti. Bây giờ là O-Toro Sushi. :)

Tôi cũng vậy; Tôi sẽ dành thời gian cho Silverlight hơn là ASP.NET MVC. Tôi đã thử MVC 1.0 và đã xem qua bản phát hành 2.0 Beta 1 mới nhất vài ngày trước.

Tôi (không thể) cảm thấy rằng ASP.NET MVC tốt hơn so với webform. Điểm bán hàng của MVC là:

1. Đơn vị (kiểm tra)
   
2. Phân tách thiết kế (khung nhìn) và logic (bộ điều khiển + mô hình)
   
3. Không có quản lý id phần tử tốt hơn và tốt hơn
   
4. URL RESTful và hơn thế nữa ...

Nhưng webform, bằng cách sử dụng mã phía sau.Theme, Skin và Resource đã hoàn hảo để phân tách thiết kế và logic.

Viewstate: quản lý id khách hàng đang đến trên ASP.NET 4.0. Tôi chỉ quan tâm đến các bài kiểm tra đơn vị, nhưng các bài kiểm tra đơn vị không đủ là lý do để biến tôi thành ASP.NET MVC từ dạng web.

Có lẽ tôi có thể nói: ASP.NET MVC không tệ, nhưng webform đã là đủ.

Tôi đã sử dụng MVC kể từ khi Bản xem trước 3 xuất hiện và trong khi nó vẫn còn đang phát triển, nó giúp ích khá nhiều trong lĩnh vực phát triển nhóm. Hãy thử để ba người làm việc trên một trang webforms duy nhất và sau đó bạn sẽ hiểu khái niệm đập đầu vào tường. Tôi có thể làm việc với một nhà phát triển, người hiểu các yếu tố thiết kế trên trang xem và vị thần Linq thường trú của chúng tôi trong việc làm cho mô hình hoạt động trong khi tôi đặt mọi thứ lại với nhau trong bộ điều khiển. Tôi chưa bao giờ có thể phát triển trong một lĩnh vực mà việc phân tách các mối quan tâm rất dễ đạt được.

Điểm bán hàng lớn nhất của ASP.Net MVC - StackOverflow chạy trên ngăn xếp MVC.

Điều đó đang được nói ... mã của bạn đẹp hơn nhiều so với những gì tôi thường làm với trang xem. Ngoài ra, một trong những người mà tôi làm việc cùng đang nghiên cứu gói trình trợ giúp HTML vào thư viện thẻ. Thay vì <% = Html.RandomFunctionHere ()%> nó hoạt động như

<hh: chức năng ngẫu nhiên />

Tôi chỉ hy vọng nhóm MVC tiếp cận nó vào một lúc nào đó bởi vì tôi chắc chắn rằng họ sẽ làm tốt hơn nó.

Sử dụng Mẫu mặt tiền để bọc tất cả logic cho tất cả dữ liệu bạn cần hiển thị và sau đó sử dụng nó làm mẫu chung trong chế độ xem của bạn và sau đó .... không còn mã spaghetti nữa. http://en.wikipedia.org/wiki/Design_potype_(computer_science)

Nếu bạn cần thêm trợ giúp cgardner2020 @ gmail

Việc triển khai ASP.NET MVC thật kinh khủng. Các sản phẩm đồng bằng hút. Tôi đã thấy một số bản demo của nó và tôi xấu hổ về MSFT ... Tôi chắc rằng những người viết nó thông minh hơn tôi, nhưng gần như họ không biết Trình điều khiển xem mô hình là gì .

Những người duy nhất tôi biết đang cố gắng triển khai MVC là những người thích thử những điều mới từ MSFT. Trong các bản demo tôi đã thấy, người thuyết trình có giọng điệu xin lỗi ...

Tôi là một fan hâm mộ lớn của MSFT, nhưng tôi phải nói rằng tôi thấy không có lý do gì để bận tâm đến việc triển khai MVC của họ. Sử dụng Biểu mẫu web hoặc sử dụng jquery để phát triển web, không chọn sự ghê tởm này.

BIÊN TẬP:

Mục đích của mẫu thiết kế kiến ​​trúc Model-View-Controller là tách biệt miền của bạn khỏi bản trình bày khỏi các quy tắc kinh doanh. Tôi đã sử dụng mẫu thành công trong mọi dự án Web Forms mà tôi đã triển khai. Sản phẩm ASP.NET MVC không cho vay đúng với mẫu thiết kế kiến ​​trúc thực tế.