thắc mắc Chuyển đổi từ .netcore MVC standard sang SPA

  • Người tạo chủ đề Người tạo chủ đề showmethemoney
  • Ngày bắt đầu Ngày bắt đầu

showmethemoney

Đã tốn tiền
Tình hình là bên em build xong 1 hệ thống tài chính cho khách hàng, hệ thống đang đi vào giai đoạn UAT rồi. Khách hàng đột nhiên có thay đổi về CTO, anh CTO mới sau khi vào test site CMS phán ngay 1 câu là cái này không được, nhất định phải đổi sang kiểu "bấm vào 1 page nào đó chỉ load lại nội dung nhưng không được reload cả page".
Em nghe xong thì biết là bác này muốn làm kiểu single page app rồi. Tuy nhiên đội dev bên em cũng là đi outsource nên để đổi solution thì bên dev tất nhiên sẽ không chịu, vì ngay từ đầu đã không chốt rõ là phải làm theo kiểu nào. Bây giờ để tối ưu chi phí thì sếp em sẽ đi đàm phán lại với khách hàng, tuy nhiên nếu không được thì vẫn phải tiến hành sửa.
Vậy theo mọi người nếu không đàm phán được thì nên triển khai theo phương án nào cho tối ưu về effort?
1. Tạo mới frontend project dựa trên SPA framework/lib nào đó, phần backend thay vì render view thì chỉ trả về json cho client
2. Phương án khác, cái này em nghĩ tự viết router cho phía frontend, sau đó vẫn call ajax để get data trả về từ MVC controller phía backend, case này em chưa thử nên chưa có kinh nghiệm để estimate lắm, nhờ ae suggest.
P/S hiện site CMS này đang viết bằng .netcore 3.1 MVC sử dụng Razor view, số lượng page trong site rơi vào khoảng 30~40 page, các view list thì chủ yếu sử dụng jquery datatable, các form nhập liệu cơ bản không sử dụng advance control gì cả.
 
1 với 2 khác nhau gì vậy. Điều phải làm lại FE và call API
Mình thấy vài hệ thống .Net vừa sử dụng cả MVC và SPA.
Bạn xem lại có cần chuyển hết tất cả sang SPA ko.
 
Sửa lần cuối:
CTO ngáo à :big_smile:
Deal lại thôi, chứ làm xong xuôi rồi ko có đổi, nếu muốn đổi thì trả tiền phase 1 trước rồi team mới làm phase 2 :look_down:
Đợi release xong hết, tổng hợp lại feedback rồi mới đổi, ko có kiểu hở tí bắt đổi nhé :confuse:
 
1 với 2 khác nhau gì vậy. Điều phải làm lại FE và call API
Mình thấy vài hệ thống .Net vừa sử dụng cả MVC và SPA.
Bạn xem lại có cần chuyển hết tất cả sang SPA ko.
Đúng là cách nào cũng phải sửa lại FE & API, nhưng phương án 2 có thể apply một số lib router như kiểu sammy js ở trên FE để giảm thiểu công sức viết lại toàn bộ page sang SPA. Cái sammy mình mới đọc thử chứ chưa apply bao giờ nên k chắc, vì vậy mới lên đây hỏi để mọi người tư vấn :D
 
CTO ngáo đá à, để chuyển đổi từ MVC sang SPA phải đánh giá đủ các tiêu chí trước khi chuyển đôi, chớ không phải thích đổi là đổi đâu.
  • Project đang project-base hay ODC
  • Size của project (team size, làm bao nhiêu năm)
  • Complexity of project business
  • SEO support?
  • Thời gian research cho tới khi implement, khả năng của team
...
Khi nào đánh giá đầy đủ thì hãy tính tới việc chuyển.
P/S: Nếu chuyển thì nên xài Angular, hợp với mấy project Fintech ni lắm.
 
Hợp đồng bên em kí là fix budget rồi.
CTO ngáo đá à, để chuyển đổi từ MVC sang SPA phải đánh giá đủ các tiêu chí trước khi chuyển đôi, chớ không phải thích đổi là đổi đâu.
  • Project đang project-base hay ODC
  • Size của project (team size, làm bao nhiêu năm)
  • Complexity of project business
  • SEO support?
  • Thời gian research cho tới khi implement, khả năng của team
...
Khi nào đánh giá đầy đủ thì hãy tính tới việc chuyển.
P/S: Nếu chuyển thì nên xài Angular, hợp với mấy project Fintech ni lắm.
  • Project đang project-base hay ODC -> project base, fix budget nên tất nhiên khách muốn càng nhiều càng tốt (trong giới hạn cho phép), cái vụ SPA này không chốt trước nên yêu cầu của họ cũng chẳng đúng chẳng sai
  • Size của project (team size, làm bao nhiêu năm) -> hiện tại dev bên e outsource có 1 ông cân luôn cái cms, cái microservices khác cũng có người làm nhưng là java
  • Complexity of project business -> cms cũng nhiều nghiệp vụ, nhưng chủ yếu là CRUD trực tiếp với db hoặc call core service, phức tạp nhất chắc là phần báo cáo thì là call core service do ông java làm lấy data để hiển thị thôi
  • SEO support? -> cms nên không cần
  • Thời gian research cho tới khi implement, khả năng của team -> đội dev thì không happy với việc chuyển lắm, khả năng em sẽ phải nhảy vào implement, thời gian thì chắc tầm 1 tới 1.5 tháng
 
Cứ theo hợp đồng mà làm, không khác gì đập đi xây lại cả. Mà 2020 rồi mà còn razor với jquery. Thằng thiết kế cái này người 10 năm trước à
cdGvfgg.png
 
deal lại, có cái lý nào tới UAT còn đòi xàm *** v?
mà mấy anh có thù với MVC à, SPA cái cc gì, nhìn trang duongdaynong tphcm đó, SPA như cc
 
Hợp đồng bên em kí là fix budget rồi.

  • Project đang project-base hay ODC -> project base, fix budget nên tất nhiên khách muốn càng nhiều càng tốt (trong giới hạn cho phép), cái vụ SPA này không chốt trước nên yêu cầu của họ cũng chẳng đúng chẳng sai
  • Size của project (team size, làm bao nhiêu năm) -> hiện tại dev bên e outsource có 1 ông cân luôn cái cms, cái microservices khác cũng có người làm nhưng là java
  • Complexity of project business -> cms cũng nhiều nghiệp vụ, nhưng chủ yếu là CRUD trực tiếp với db hoặc call core service, phức tạp nhất chắc là phần báo cáo thì là call core service do ông java làm lấy data để hiển thị thôi
  • SEO support? -> cms nên không cần
  • Thời gian research cho tới khi implement, khả năng của team -> đội dev thì không happy với việc chuyển lắm, khả năng em sẽ phải nhảy vào implement, thời gian thì chắc tầm 1 tới 1.5 tháng
Nếu là project base thì không khuyến khích việc thay đổi techstack giữa chừng, trừ khi tech stack hiện tại có technical debt hay muốn làm lâu dài. Bạn nên thảo luận với PM và CTO để ra quyết định, nếu PM đồng ý thì làm không thì thôi.
Mình đưa ra một số chi phi nếu chuyển từ MVC sang SPA
1. Learning curve: cả team phải học SPA framework
2. Thay đổi back-end từ MVC sang Rest API (chi phí này cực lớn)
3. Thay đổi Authentication/Authorization từ session base sang JWT, tương ứng ở front-end
4. Thay đổi selector trong bộ Automation test (Selenium), có khi phải chuyển qua framework test chuyên dụng cho SPA
5. Thay đổi quy trình CI/CD để build và deploy app
6. Thay đổi cấu hình loadbalancer (remove cái sticky session)
7. Thay đổi quy trình integration test theo mô hình Rest API - SPA
Còn vài cái nữa mà mình quên rồi, sẽ update thêm nếu nhớ :D
 
Nếu là project base thì không khuyến khích việc thay đổi techstack giữa chừng, trừ khi tech stack hiện tại có technical debt hay muốn làm lâu dài. Bạn nên thảo luận với PM và CTO để ra quyết định, nếu PM đồng ý thì làm không thì thôi.
Mình đưa ra một số chi phi nếu chuyển từ MVC sang SPA
1. Learning curve: cả team phải học SPA framework
2. Thay đổi back-end từ MVC sang Rest API (chi phí này cực lớn)
3. Thay đổi Authentication/Authorization từ session base sang JWT, tương ứng ở front-end
4. Thay đổi selector trong bộ Automation test (Selenium), có khi phải chuyển qua framework test chuyên dụng cho SPA
5. Thay đổi quy trình CI/CD để build và deploy app
6. Thay đổi cấu hình loadbalancer (remove cái sticky session)
7. Thay đổi quy trình integration test theo mô hình Rest API - SPA
Còn vài cái nữa mà mình quên rồi, sẽ update thêm nếu nhớ :D
không có nhiều đến thế đâu thím ơi, đơn giản chỉ là allocate thêm FE để support rồi vẫn chạy theo luồng cũ thôi
 
đàm phán lại với bên kia, nhu cầu là gì khi cần "bấm vào 1 page nào đó chỉ load lại nội dung nhưng không được reload cả page".
Thực tế trãi nghiệm sử dụng không khác mấy nếu chức năng không yêu cầu nặng về UI/UX. Còn nếu build dạng REST API để sau này dễ phát triển thêm về mobile hoặc tích hợp với bên thứ 3 thì nghe có vẻ hợp lý hơn.
Còn nếu thực sự hiện tại UI/UX đang có vấn đề ảnh hưởng đến người dùng, hoặc không đáp ứng được yêu cầu thì xem lại với công nghệ hiện tại có giải pháp không.

Tóm lại phải trao đổi lại với khách hàng, họ cần điều gì khi muốn chuyển sang một giải pháp khác.
 
nchung là đập stack là dở rồi.

Nhưng tầng application nếu thiết kế tốt thì chỉ cần sửa lại controller thôi, chứ proj viết lởm khởm thì no hope luôn
 
Cứ theo hợp đồng mà làm, không khác gì đập đi xây lại cả. Mà 2020 rồi mà còn razor với jquery. Thằng thiết kế cái này người 10 năm trước à
cdGvfgg.png
Ông này sinh năm 88, bê nguyên con CMS làm cho 1 bank apply vào đây =))
deal lại, có cái lý nào tới UAT còn đòi xàm *** v?
mà mấy anh có thù với MVC à, SPA cái cc gì, nhìn trang duongdaynong tphcm đó, SPA như cc
Thực ra CMS thì trải nghiệm lúc reload tôi thấy cũng k phải là tệ lắm, chả hiểu sao mr CTO lại dị ứng như thế. Pen test, stress test, HA test chả thấy comment gì, duy có cái này rất gay gắt
Nếu là project base thì không khuyến khích việc thay đổi techstack giữa chừng, trừ khi tech stack hiện tại có technical debt hay muốn làm lâu dài. Bạn nên thảo luận với PM và CTO để ra quyết định, nếu PM đồng ý thì làm không thì thôi.
Mình đưa ra một số chi phi nếu chuyển từ MVC sang SPA
1. Learning curve: cả team phải học SPA framework
2. Thay đổi back-end từ MVC sang Rest API (chi phí này cực lớn)
3. Thay đổi Authentication/Authorization từ session base sang JWT, tương ứng ở front-end
4. Thay đổi selector trong bộ Automation test (Selenium), có khi phải chuyển qua framework test chuyên dụng cho SPA
5. Thay đổi quy trình CI/CD để build và deploy app
6. Thay đổi cấu hình loadbalancer (remove cái sticky session)
7. Thay đổi quy trình integration test theo mô hình Rest API - SPA
Còn vài cái nữa mà mình quên rồi, sẽ update thêm nếu nhớ :D
1. Learning curve: cả team phải học SPA framework -> cái này thì phải chấp nhận, tệ nhất là thuê ngoài nếu team k adapt kịp
2. Thay đổi back-end từ MVC sang Rest API (chi phí này cực lớn) -> cái này không nhiều, thay vì return data để razor view render thì mình return json view
3. Thay đổi Authentication/Authorization từ session base sang JWT, tương ứng ở front-end -> hệ thống bao gồm cả mobile nên vẫn authen bằng jwt, coi như cũng bớt được chút ít workload
4. Thay đổi selector trong bộ Automation test (Selenium), có khi phải chuyển qua framework test chuyên dụng cho SPA -> không có auto test b ơi =))
5. Thay đổi quy trình CI/CD để build và deploy app -> Hiện team đã có ci/cd chạy rồi, cái này chỉ change 1 lần, cũng k phải vđ lắm.
6. Thay đổi cấu hình loadbalancer (remove cái sticky session) -> hiện đang dùng nginx cho api nên mình nghĩ sẽ không có vấn đề gì chứ nhỉ?
7. Thay đổi quy trình integration test theo mô hình Rest API - SPA -> maybe
Anw cảm ơn các bác đã tư vấn, đặc biệt là @hoangquan91
 
nchung là đập stack là dở rồi.

Nhưng tầng application nếu thiết kế tốt thì chỉ cần sửa lại controller thôi, chứ proj viết lởm khởm thì no hope luôn
Đúng bác, giờ chỉ đổi lại một chút ở controller để return json tương ứng. Phần đau đầu nhất là FE
 
trước cũng thích chuyển qua spa, về sau thấy kết hợp cả 1 trong 2 (angularjs, vuejs) là đủ, chuyển hết tốn sức lực thời gian mà hiệu quả ko quá đáng giá.
 
Nể CTO nhỉ, không cân nhắc gì à, datatable jquery cũng đâu phải là gì lởm cho cam, xịn là đằng khác. Để đánh giá thì phải đánh giá cả phần con người nữa chứ, ông giao thêm feature chúng nó làm cái 1, hay là lại ngồi chờ học xong rồi mới làm? Còn tốc độ, còn fix bug, còn có khi thay cả hành vi nữa ???
2y9npcU.png
2y9npcU.png
2y9npcU.png
 
Nói mới nhớ làm với MVC Core có cái sướng là dễ dàng chuyển đổi controller giữa MVC và API, không như MVC Framework cũ :D
Dễ là sao nhỉ, em tưởng .NET core với .NET thì cũng phải đập controller luôn xây lại chứ đâu khác gì nhau ta.
 

Thống kê chủ đề

Ngày tạo
showmethemoney,
Người trả lời cuối
asida118,
Trả lời
42
Lượt xem
4.728
Quay lại
Lên đầu trang