MVC cổ điển đến ASP.net hoặc ASP.net

Chúng tôi có một ứng dụng web được phát triển trong ASP cổ điển và nó đã phát triển hơn 5 năm so với hình thức hiện tại có 100 trang, cơ sở dữ liệu khổng lồ và hơn 10000 người dùng hoạt động trải qua ít nhất hơn 10 trang mỗi ngày.

Bây giờ, chúng tôi muốn nâng cấp nó lên phiên bản mới nhất của .net. Ban đầu chúng tôi nghĩ rằng viết lại toàn bộ ứng dụng, nhưng sau khi phân tích kịch bản, chúng tôi thấy rằng đó không phải là một lựa chọn khả thi cũng không được đề xuất bởi nhiều chuyên gia. Chúng tôi chưa quyết định làm thế nào để làm điều đó bằng cách khác, nhưng có một số suy nghĩ về cách để đạt được việc viết lại trên khuôn mặt.

Tùy chọn 1: Chúng tôi đã nghĩ đến việc xác định các mô-đun chính trong ứng dụng này và viết lại từng mô-đun bằng cách tách ứng dụng thành các lớp khác nhau như cơ sở dữ liệu (hiện có), sau đó là logic nghiệp vụ và khung nhìn. Bằng cách này, các mô-đun mới được phát triển sẽ được thêm vào hệ thống hiện có và các trang mới sẽ thay thế các trang cũ trong mô-đun cụ thể đó. Đồng thời chúng tôi có thể kiểm tra các lớp mới cùng với hệ thống cũ và phát hành chúng một khi chúng tôi cảm thấy tự tin. Chúng tôi cũng đã nghĩ đến việc phát triển loại cấu trúc API cho logic nghiệp vụ và điều này sẽ được truy cập bằng cách xem như một ứng dụng bên ngoài.

Tùy chọn 2: Hiện tại chúng tôi đã thực hiện một mô-đun đơn giản và sử dụng nó trong trang ASP cổ điển thông qua IFrame, mặc dù việc gửi dữ liệu giữa ASP cổ điển và trang mới trong IFrame cổ điển khá rắc rối.

Đây chỉ là trong giai đoạn lập kế hoạch về cách chúng ta nên đạt được việc viết lại toàn bộ ứng dụng mà không làm phiền cơ sở người dùng.

Tôi muốn nhận được các quan điểm, ý kiến ​​và đề xuất của các lập trình viên khác về việc chúng ta có nên tiếp cận trong kịch bản như vậy không? nếu bất cứ ai đã phải đối mặt với loại kịch bản này, xin vui lòng chia sẻ ý kiến ​​của bạn quá.

Cũng muốn biết việc sử dụng ASP.net MVC sẽ giúp tôi trong việc này?

CẬP NHẬT : Cảm ơn cả hai câu trả lời đã đưa ra quan điểm của bạn. Muốn nhận thêm đầu vào trên cả hai tùy chọn tôi đã chỉ định ở trên khi di chuyển ứng dụng từ asp cổ điển sang asp.net hoặc asp.net mvc. Nó sẽ giúp ích rất nhiều cho tôi, nếu tất cả các bạn đều có thể thông qua quan điểm, quan điểm và suy nghĩ của mình về phần di chuyển thay vì quan điểm chọn asp.net hoặc asp.net mvc.

Hãy để tôi bắt đầu bằng cách nói, "Tôi cảm thấy nỗi đau của bạn, brutha." Tôi đã trải qua điều này 3 năm trước và tôi ước rằng MVC đã trưởng thành vào thời điểm đó bởi vì giải pháp WebForms mà tôi thiết kế khá giống với mô hình MVC mà không thực sự có các thư viện Microsoft được xây dựng cho tôi (tất nhiên, có một vài câu "Tại sao chết tiệt tôi đã làm điều đó "sự khác biệt).

Tôi cũng đã kết thúc việc sử dụng iFrames để quản lý sự khác biệt nội dung bằng cách sử dụng .Net làm ứng dụng mẹ và asp cổ điển làm nô lệ. Tôi đã phát triển kiến ​​trúc khung trong .Net và thực hiện điều đó. Các trang asp cổ điển sau đó đã được "loại bỏ" các phần trình bày không cần thiết (bao gồm và không có gì) và được tải vào iFrames. Dữ liệu sau đó được truyền qua url bằng mã hóa tùy chỉnh. Để đảm bảo rằng xác thực không thể bị giả mạo một cách dễ dàng và trang được truy cập bằng cách bẻ khóa chuỗi truy vấn, chúng tôi cũng đã sử dụng các trình xử lý Wildcard trong IIS đã buộc .Net phải xác thực trước khi phân tích các trang asp cổ điển.

Do đó, khuyến nghị của tôi là hướng tới MVC ngay lập tức.

1. MVC sẽ cung cấp cho bạn quyền truy cập để định tuyến ở cấp độ global.asax. Với thao tác thông minh của bộ điều khiển, bạn có thể phát triển các mô hình của mình theo cách phù hợp và có một bộ điều khiển chung xử lý tất cả các yêu cầu asp cổ điển khi cần thiết.
2. MVC sẽ làm cho nó rất đơn giản để thêm một dự án thử nghiệm và cho phép bạn cấu trúc lại các phần ứng dụng riêng lẻ dựa trên cấu trúc mô hình mới trong khi cung cấp phạm vi kiểm tra đầy đủ để đảm bảo bạn sẽ ổn. Giá trị của điều này là hoàn toàn khôn lường bởi vì trong bất kỳ phạm vi bảo hiểm mã tái cấu trúc nào là một mối quan tâm lớn.
3. MVC tuân theo cách tiếp cận theo kịch bản để trình bày hơn so với WebForms. WebForms cố gắng kết hợp tất cả lại giống như một loại ứng dụng trạng thái (không phải vậy) và đó có thể là một cú sốc văn hóa đối với những người quen với asp cổ điển. Đừng hiểu sai ý tôi, các nhà phát triển của bạn sẽ bị sốc văn hóa bất kể bạn đi theo hướng nào, nhưng nếu bạn có thể loại bỏ cú sốc đó ra khỏi lớp trình bày, bạn có thể tìm thấy thành công lớn hơn.

Tôi thích cả WebForms và MVC (mặc dù tôi sẽ thừa nhận với việc giới thiệu về Dao cạo Tôi trở nên hơi thiên vị đối với MVC). Cả hai đều có vị trí của họ và tôi nghĩ rằng một ứng dụng như ứng dụng bạn mô tả có thể phù hợp lý tưởng cho việc triển khai MVC đặc biệt có tính chất "so le" mà bạn sẽ cần áp dụng khi triển khai các phần ứng dụng được tái cấu trúc.

Dù bạn đi bằng cách nào, tôi nghĩ bạn cần đảm bảo rằng ứng dụng .Net luôn là ứng dụng mẹ khi nói đến xác thực / ủy quyền / định tuyến / vv. Một đồng nghiệp của tôi đã thực hiện việc di chuyển của anh ấy trên một ứng dụng tương tự với asp cổ điển là cha mẹ và anh ấy đã gặp phải một số vấn đề lớn khi cuối cùng đã tích hợp mọi thứ lại với nhau.

Sử dụng ASP.NET MVC sẽ không làm cho quá trình chuyển đổi trở nên dễ dàng hơn, và thực tế nó có thể làm cho nó khó khăn hơn. Tuy nhiên, khi bạn đã chọn để thực hiện công việc vĩ đại này, tại sao không dành thời gian để tiếp tục và chuyển sang nền tảng phù hợp nhất với kế hoạch của bạn?

Di chuyển sang ASP.NET (sans MVC) sẽ "dễ dàng" hơn theo nghĩa là bạn thường có thể thực hiện các cổng thẳng của logic hiện tại mà không phải thực hiện nhiều thao tác tái cấu trúc, miễn là bạn không làm nhiều điều kỳ lạ với cổ điển ASP. Kết quả sẽ thỏa đáng và tương đối quen thuộc với những người đã quen thuộc với ứng dụng này. Bạn sẽ đạt được lợi ích theo nghĩa là mọi ứng dụng được chuyển từ ASP cổ điển sang ASP.NET đều nhận được lợi ích .

Di chuyển sang ASP.NET MVC sẽ có nhiều công việc hơn. Nó có thể sẽ yêu cầu nghiên cứu lại mô hình ứng dụng của bạn để phù hợp với mô hình MVC . Đây thường là một điều tốt (tm) vì nó khuyến khích các hành vi tốt như tách biệt các mối quan tâm. Ứng dụng kết quả sẽ không giống với bất cứ thứ gì bạn có ngoại trừ các phần logic cốt lõi. Bạn cũng sẽ nhận được những lợi thế khác . Đây sẽ là một sự thay đổi văn hóa lớn và sẽ cần một số (giáo dục) của nhóm phát triển để hiểu "cách viết MVC" đúng cách.

Đáng chú ý, Microsoft sẽ không từ bỏ WebForms theo ScottGu (như một năm trước), nhưng tôi không nghĩ rằng thật khó để thực hiện cuộc gọi rằng nếu / khi họ quyết định loại bỏ một trong hai công nghệ này, thì nó sẽ WebForms.

Tôi hoàn toàn đồng ý rằng ASP.NET MVC là con đường để đi. Nó sẽ không dễ dàng, nó sẽ không dễ dàng hơn, nhưng nó chắc chắn là bằng chứng trong tương lai nhiều hơn so với WebForms. Mặc dù WebForms chắc chắn đã không bị bỏ rơi, các ứng dụng sử dụng chúng ngày càng trở nên cồng kềnh khi các ứng dụng ngày càng lớn hơn.

Tôi đặc biệt không khuyến khích việc sử dụng WebForms trên các ứng dụng "lớn".

Tôi thích Tùy chọn 1) (với MVC) tốt hơn nhiều so với Tùy chọn 2) vì nó cho phép bạn phát triển ứng dụng dần dần, trong khi không phải ghép hai ứng dụng quá nhiều như cách tiếp cận iFrames.

Tôi đã có một số kinh nghiệm khi chuyển một ứng dụng cũ sang ASP.Net và một trong những thách thức là chia sẻ một số tài nguyên như trạng thái phiên giữa hai ứng dụng. Điều đó có thể được giải quyết bằng cách một ứng dụng gọi ứng dụng khác ở phía máy chủ thông qua thông tin cookie từ trình duyệt của người dùng. Tất nhiên, việc chia sẻ thông tin khác giữa các ứng dụng cũng có thể được thực hiện thông qua các chuỗi truy vấn và định tuyến URL, đây là một cách tiếp cận tự nhiên với MVC.

Ngoài ra, việc xác định các mô-đun thích hợp để di chuyển trước có thể là một thách thức, nhưng bạn có thể bắt đầu với tất cả chức năng mới được phát triển trên MVC để ngăn chặn nhiều thứ kết thúc trong nhà để xe được di chuyển. Sau đó, có thể chọn các phần tồn đọng đáng kể của việc làm lại hoặc sửa lỗi sẽ được thực hiện tiếp theo vì ứng dụng MVC sau đó sẽ trở thành một hình thức tái cấu trúc, sử dụng hệ thống cũ của bạn để thiết lập kết quả mong đợi như bạn đề xuất. Đừng quên tận dụng khả năng kiểm tra của MVC bằng cách thêm kiểm tra đơn vị và kiểm tra chấp nhận tự động (ví dụ SpecFlow / Watin) trong quá trình tái cấu trúc này. Một lợi thế của loại thử nghiệm sau là bạn có thể xác minh rằng chúng vượt qua hệ thống cũ và sau đó áp dụng các thử nghiệm tương tự cho mã mới của bạn cho lần tái cấu trúc này và trong tương lai.