Should I upgrade to asp.net MVC

D

donvilla07

Well-Known Member
Joined
Feb 6, 2017
Messages
140
Reaction score
13
Location
Randburg
Our organisation has a web application developed by a third party, using asp.net framework and written in VB.NET. Our developers are suggesting upgrading the application to asp.net MVC, which will also allow them to write the code in C#. There are a few reasons for the suggested upgrade as per our developers, such as:
1. Developers in college don't know asp.net or VB.NET, which makes the learning of our application that much more difficult
2. MVC is faster and more reliable
3. .net framework is no longer being actively developed
4. MVC has better security
5. Site responsiveness is built into MVC

While we do trust our developers, I am looking for further opinions before making the leap. Is it worth the money which will need to be invested? Is this framework the right option, considering a long-life span?

Any help would be greatly appreciated.
 
What about donet core? Of course any framework or implementation is only as good as its proper usage and being the right tool for the right job..
 
Nemoneiros said:
What about donet core? Of course any framework or implementation is only as good as its proper usage and being the right tool for the right job..
Click to expand...

You can run mvc on core. MVC is a design pattern, certainly agree you should move away from vb but i would quiz them on persistance and how closely coupled you want your website.

Mvc,. Net and they will prob propose entity are both in the long run and not fly by night frameworks but it's really just a framework, a lot will depend on how it's put together and written.
 
cheesus said:
Source?
Click to expand...
It's supported by Microsoft but they are moving away from it. The .Net Standard base from v2.1 does not include anymore .net framework changes and microsoft have blogged that they will be reducing the new functionality on the framework.

docs.microsoft.com

.NET Standard - .NET

Learn about .NET Standard, its versions, and the .NET implementations that support it.
docs.microsoft.com

Let me see if I can find the blog post.

devblogs.microsoft.com

Introducing .NET 5

Today, we’re announcing that the next release after .NET Core 3.0 will be .NET 5. This will be the next big release in the .NET family. There will be just one .NET going forward, and you will be able to use it to target Windows,
devblogs.microsoft.com devblogs.microsoft.com

This explains the road map a bit better.


Basically, MS are trying to get rid of the old deprecated api's and .net core is the new base which will eventually become the defacto .net

Having said that, the differences between core and framework are not huge for a developer to learn and a lot of the newer language features which make it easier are in core. But yes, businesses should consider a movement strategy away from .net framework due to the deprecation but I still see lots of code floating around with even .net 1.1 or 2.0 kicking. Most business are of the opinion if it ain't broke don't fix it and unless there is a drastic issue with a legacy systems, they don't migrate. Short sighted but that is quite common. Problem when code you wrote a decade ago still functions perfectly.
 
Last edited:
Thanks for the opinions thus far. Does seem like it is the correct move to make based on this and my own research.
 
Kosmik said:
You can run mvc on core. MVC is a design pattern, certainly agree you should move away from vb but i would quiz them on persistance and how closely coupled you want your website.

Mvc,. Net and they will prob propose entity are both in the long run and not fly by night frameworks but it's really just a framework, a lot will depend on how it's put together and written.
Click to expand...
Sure, but is the OP talking about the framework, the pattern or both? In any case, one should look at the ability to actually use it correctly and the use case(s) vs just-yes-man-it.

I replied as I did because it almost sounded like the MVVM pitch I heard a few years ago...
 
Nemoneiros said:
Sure, but is the OP talking about the framework, the pattern or both? In any case, one should look at the ability to actually use it correctly and the use case(s) vs just-yes-man-it.

I replied as I did because it almost sounded like the MVVM pitch I heard a few years ago...
Click to expand...
I think changing the entire framework would be too much work and I don't think it's necessary.
Certainly agree that whatever decision is made, it has to be implemented and used correctly. Given that our dev team is familiar with asp.net MVC probably makes this decision a bit easier.
 
donvilla07 said:
1. Developers in college don't know asp.net or VB.NET, which makes the learning of our application that much more difficult
Click to expand...
"Finished" college (my diploma a few years ago), I'd literally decline the position no matter what if you tried to force me to use VB.NET.

Not sure why MVC is faster or more reliable? It's a design pattern and would definitely help maintainability if you aren't using any architecture pattern currently, and you could even do this in VB.NET but you'd probably have to refactor everything, but it would be worth it. I think it would be scary looking at your code base, tickets probably taking forever to resolve...

What service are you actually running? Is it large enough to warrant a micro-service approach? I'd at least split the web app into a separate piece, use API requests to get the info you need to display, keep most of the business logic on the back-end. Would allow you to use e.g. Vue.js for the client-side application, would allow you to use hot reloading, which is great for sites that are data driven.

Note that you can also use the built-in templates if you want to go with Angular or React instead.
741611


EDIT:
Btw, I'd take advantage of the docker support, will make life easier once you get used to it.
And you might be interested in: https://github.com/RickStrahl/Westwind.AspnetCore.LiveReload if you're sticking with a "pure" ASP.NET Core build to make development of views easier.
 
Last edited:
VB.Net is very much a legacy language. Part of the .Net Framework more because of the historical significance it has had to the MS stack and the massive amounts of legacy systems that still interact with it. I don't know why exactly any new work would be done on/with it.
 
donvilla07 said:
I think changing the entire framework would be too much work and I don't think it's necessary.
Certainly agree that whatever decision is made, it has to be implemented and used correctly. Given that our dev team is familiar with asp.net MVC probably makes this decision a bit easier.
Click to expand...

Not really that difficult. My personal favorite and suggestion would be to do an MVC site on core but with a separated API backend so the logic can be used elsewhere as well.
 
Johnatan56 said:
"Finished" college (my diploma a few years ago), I'd literally decline the position no matter what if you tried to force me to use VB.NET.

Not sure why MVC is faster or more reliable? It's a design pattern and would definitely help maintainability if you aren't using any architecture pattern currently, and you could even do this in VB.NET but you'd probably have to refactor everything, but it would be worth it. I think it would be scary looking at your code base, tickets probably taking forever to resolve...
Click to expand...

MVC is a design pattern. Microsoft MVC is a framework based on the MVC design pattern. I haven't used it myself, but I know it gives you a bunch of stuff "for free", which you would otherwise have to code yourself (or get from another framework) like routing. These days I think you can get most of it outside of MS MVC, but their old VB.Net app definitely won't have it.
 
donvilla07 said:
Our organisation has a web application developed by a third party, using asp.net framework and written in VB.NET. Our developers are suggesting upgrading the application to asp.net MVC, which will also allow them to write the code in C#. There are a few reasons for the suggested upgrade as per our developers, such as:
1. Developers in college don't know asp.net or VB.NET, which makes the learning of our application that much more difficult
2. MVC is faster and more reliable
3. .net framework is no longer being actively developed
4. MVC has better security
5. Site responsiveness is built into MVC

While we do trust our developers, I am looking for further opinions before making the leap. Is it worth the money which will need to be invested? Is this framework the right option, considering a long-life span?

Any help would be greatly appreciated.
Click to expand...
If it aint broke, dont fix it

Just because the technology is better than what you current have, doesnt mean it will be implemented without any bugs. Many a project has floundered on this.

Ofc, the definition of broke is another whole debate which is unique to each organisation.

Instead of rewriting the whole thing, think about shifting functionality to a new platform in logical bits which offer the least risk.
 
zippy said:
If it aint broke, dont fix it

Just because the technology is better than what you current have, doesnt mean it will be implemented without any bugs. Many a project has floundered on this.

Ofc, the definition of broke is another whole debate which is unique to each organisation.

Instead of rewriting the whole thing, think about shifting functionality to a new platform in logical bits which offer the least risk.
Click to expand...
Within reason, if he's having trouble hiring new maintainers, then he should look at migration. I also disagree with your statement a bit, things like GUI should be constantly updated/brought up to modern design, it's what the user constantly interacts with and it would be difficult to sign up new users if the design looks outdated, since people will assume the project is not being maintained. It's why I don't like having GUI integrated directly with back-end, should be completely separated and information should be fetched via API (be it Rest or GraphQL).
 
I hope “migrate” means “create new features/screens/product on a new platform, and potentially move old functionally as and when needed” and not “rewrite the entire existing business on a new platform”

the first is easy to achieve.
the 2nd is a fools game.
 
_kabal_ said:
I hope “migrate” means “create new features/screens/product on a new platform, and potentially move old functionally as and when needed” and not “rewrite the entire existing business on a new platform”

the first is easy to achieve.
the 2nd is a fools game.
Click to expand...
I have a VS2008 project that I have tested on VS2015 and it ran okay. Asp net 2.0 with 3.5 framework in place.

Development is not our core business but the application supplemented it so it worked well enough for the customer. Unfortunately the simple site had grown over the years with feature requests and a whole lot of subsystems unrelated to our core business. I could throw in a something to their requirements faster than them getting a project proprosal to their in house team.

Now there is a new spec on an old system and I was wondering if MVC could be applied to newer screens leaving the old project subsystems in place.

Updating to .net core and MVC needs migration and testing of code? Rewrites? Updating the IIS setting? Remember development is a secondary service and I need to update my skills.

I have it deployed to system.blahblah.co.za which is exposed via VPN to many external users. If i could i would go with a new site with updated technology on systemnew.blahblah.co.za but it is not feasible.

Sitting and maintaining the existing code on outdated technology vs expensive rewrite? Can I bring in new tech without breaking (or introducing obscure bugs in migration) existing from what I have in place (above)?
 
Vis1/0N said:
I have a VS2008 project that I have tested on VS2015 and it ran okay. Asp net 2.0 with 3.5 framework in place.

Development is not our core business but the application supplemented it so it worked well enough for the customer. Unfortunately the simple site had grown over the years with feature requests and a whole lot of subsystems unrelated to our core business. I could throw in a something to their requirements faster than them getting a project proprosal to their in house team.

Now there is a new spec on an old system and I was wondering if MVC could be applied to newer screens leaving the old project subsystems in place.

Updating to .net core and MVC needs migration and testing of code? Rewrites? Updating the IIS setting? Remember development is a secondary service and I need to update my skills.

I have it deployed to system.blahblah.co.za which is exposed via VPN to many external users. If i could i would go with a new site with updated technology on systemnew.blahblah.co.za but it is not feasible.

Sitting and maintaining the existing code on outdated technology vs expensive rewrite? Can I bring in new tech without breaking (or introducing obscure bugs in migration) existing from what I have in place (above)?
Click to expand...
Dont know of any upgrade which hasn't had issues. Unless its a very simple system. At some point it has to be done. When is the hard part. Too soon and you create unnecessary risk and cost making the new system worse the old one Too late and... yes, you create risk and cost by because you lag behind your competitors. . New tech is never a guarantee of success. Its the implementation that makes the difference.

The important point is understanding that there is risk and cost. Evaluating this for your business and then taking a decision and if that decision is to proceed, proceed with proper planning etc.. Then have the right people do the job. Its a process every organisation has to go through at some point. No getting away from it if you want to compete.

Just look at how others have done it. Microsoft, Apple, Google. You will notice that after each upgrade, there are minor updates. Guess what they usually are ? fixes for bugs introduced by the upgrade. Or features that didnt make it in time for the main release. Whichever way you want to spin it to management and customers :)

If you are lucky you will be releasing the upgrade knowing which bugs are in it, but have assessed the risk as being low and can be fixed later. Its the ones you dont know about that will make your life interesting post release. And yes, folks do release changes knowing there are bugs. Its all about risk vs reward.
 
Johnatan56 said:
Within reason, if he's having trouble hiring new maintainers, then he should look at migration. I also disagree with your statement a bit, things like GUI should be constantly updated/brought up to modern design, it's what the user constantly interacts with and it would be difficult to sign up new users if the design looks outdated, since people will assume the project is not being maintained. It's why I don't like having GUI integrated directly with back-end, should be completely separated and information should be fetched via API (be it Rest or GraphQL).
Click to expand...
Within reason :)
Users generally dont like change. Especially when you are dealing with large organisations. Constant changes leads to confusion and too frequent releases can result in unstable production systems which can lead to high costs, which in turn leads to your bonus getting cut.

Ofc you need to keep your systems as competitive as possible. My point is that upgrading just for the sake of upgrading is really bad business practice. You dont do upgrades simply because the developer wants to install the latest and greatest.
 
Another point about upgrading GUI's. We have a policy where developers spend a morning or afternoon with users at least once every 8 weeks or so(not a strict time, it just works out that way with the rotation). As devs we often take the pi** out of our users. Yes they arent brightest, but watching them work is quite an eye-opener. These folks can type. effing fast. The mouse is a bottleneck. The tab key is king. These folks get paid based on their throughput and converting quotes to paid up policies.

When you change the GUI, you seriously f***k with their performance. And therefore their take home pay. And its not just their take home pay. This means the less they earn, the lower the sales are, and this invariably comes back to hurt everyone. Including the developers.

Developers need to understand the impact of their work on end users and the business.
 
You must log in or register to reply here.
Back
Top
Sign up to the MyBroadband newsletter
X