Aspnetcore: MVC is too complex to be usable?

If you're not a fan of ORMs (Object Relation Mappers) like EntityFramework, you can write the SQL by hand using ADO.NET. You can also use a light weight ORM like Dapper that doesn't generate queries (you get to write them by hand). EntityFramework also has an ExecuteSQL method to give you more control when necessary (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

Also, if MVC looks too complex for simple pages, try out Razor Pages

I highly suggest you follow one of the many MVC tutorials; one cannot expect to understand something as if by magic just from 5 minutes looking at the new project template.

As for the simplicity relative to webforms, might I remind you of the misfortune of viewstate, runat=server and god save us all from the page lifecycle.
Kind regards

This is funny.

Seems pretty straightforward to me.

Also, if MVC looks too complex for simple pages, try out Razor Pages

Have just finished a WebForms -> RazorPages migration project - To be honest could have just been plain MVC but definitely a good option for small 'page-centric' websites. In MVC projects I find I'm 'hunting' code too much, ie. jumping from View to Controller constantly, scrolling through reams of Actions whereas in RazorPages I'm just going straight to PageModels.

I hate bloated EF - Dapper is so much simpler, especially if used with something like Dapper.FastCRUD

It's not just you @LJ9999 , MVC and any framework does not have all the answers. It might not be the best structure suited to your project, and it might not be a fit with how you think. No need to try to fit square pegs into round holes unless you like self-punishment.

MVC is one of your options. Evaluate a few different approaches, and choose the one that's the best fit for you. Find something that makes sense to you. Find (or make) something in which you're most productive. Don't be swayed by what's popular. Popular is not always about merit, and even what's a merit for one case doesn't work elsewhere.

So let me join you in being skeptical about the most common way things get done. Being skeptical about the approach everyone takes, and thinking critically and for yourself is a good place to start. If you think you can do better, you probably can. Go for it!

For anyone reading who feels this as an attack on them and their chosen popular way, it's really not an attack on you. It is saying find what works for you. And so it's just a statement about how, while computers might all run on the same language, people's minds don't. Everyone is different, and that's great.

+1 to dapper, use it.

As to why you use entity framework, it's a quick and easy way to express your desired behavior in the same language you define your code in, with code gen supoort (read: reduced time to market). I don't generally use it though, and you don't have to either.

It seems like you may more be taking issue to its usage in an example. The answer to that is the target audience: more people are versed in ORM paradigms in 2019 than are actually skilled in SQL. SQL isn't dead, it just has a lot of strong competition with high penetration in the younger developer contingent.

As someone who has gone through every iteration of Asp.Net, and MVC through to what we have now with Asp.Net Core I can tell you that debugging page lifecycle bugs and trying to create anything of any relative complexity with webforms was a nightmare compared to MVC. WebForms hide a lot of the actual work going on behind what seem like magical events. It abstracts the entire way web requests work by trying to hold your hand and pretend that the web is not stateless. It lies to you and tells you that you're pretty and that your butt looks good in those jeans. It falsely builds your confidence and makes web technologies fuzzy. And you blissfully go on about your day thinking that if you can make a web page with a form on it and have it save to a table then you can do anything. Until you get that new requirement to build out a custom dynamic form. Or make something work with this particular client side framework, because the client thinks it's pretty. You realize you are now working against the tide and wonder how everyone else is doing it.
MVC is not rocket science, it's a proven pattern that has evolved in the development community after realizing "there has to be a better way" and years of sticking round pegs in square holes. If you think it's complicated it's probably because you haven't encountered any of the problems it's supposed to fix and you haven't spent enough time solving complex problems. Start with simpler tutorials if this one is overwhelming.
If you decide this is not for you there's always PHP or NodeJs.

For something that is more than a trivial join, I would just use EF's ExecuteSQL. I do think you might under estimate the complexity it might be trying to represent because it doesn't have a way to name join tables logically and it might need to be flexible with the office assignment. If you don't like EF, you aren't alone. Most people using MVC probably aren't using EF. One doesn't require the other.

Personally I find webforms to be far more complicated than MVC because they have so much complex event logic obscuring what is actually a request response cycle. MVC for someone who has never thought about it is difficult at first because it is a different model of organization, but after years of usage, the industry seems to have decided that MVC is actually simpler in the long run. It's just a matter of preference, but opening a ticket like this on a tech that has been mainstream for years is just venting.

I recommend learning MVC with examples that do not use entity framework so that you learn a single concept at once. However, this isn't really the correct place to chat about it.

OMG I'm laughing so hard right now.

Look buddy, if it seems too hard or complex then step away from it and use something else. No one is holding a gun to your head, right?

Some of us have been around the block a few times and prefer the simplicity of asp mvc over web forms because we've had to deal with the horrendous pile of untestable spaghetti code that comes out of monolithic web forms monstrosities.

But seriously, if you like web forms, and someone is willing to pay you to code web forms, then do it! And stop whining about stuff you don't understand.

Is this a satire post? Not sure if on reddit or github...

I have worked on ERPs development under Asp.net web forms, and Asp.net MVC for two different systems, I can confidently say that working on web forms is a torture especially when you have a huge solution with poor architecture, and on the contrary MVC can magically turn an ugly looking architecture to a top level solution with the ability to organize layers and make use of repository pattern with strong reliable ORM such as EF.
but honestly most of the developers I have met who complains about MVC are suffering from limited experience and knowledge of the new pattern.
I personally advise developers who want to learn MVC from zero to hero to try out https://www.pluralsight.com instead of touring the web and wasting time and money on controversial topics and blogs on MVC that is in many cases biased or poor in the context.

Wow, that time has changes developers is a actually true. I praised Microsoft at how easy and straight forward EF and MVC were when I first encountered it in 2013. Like it's been said already, understanding these frameworks doesn't happen auto-magically! Follow the tutorials, watch a few of the hundreds of videos out there and try again. Sorry man but you develop an understanding of these things as you spend time with it

I agree with author. For those of people using mvc for the first time. The approach is not as friendly as the others like php, rail .. too much concept to understand before using it. However, once you got the concept, mvc seem to be very effective.

Why would anyone hate entity framework. I've had to write not more than 5 SQL queries in the last three years.

While this isn't rocket science, at the the end there is some sience behind it and as with everything, it may take some time and effor to fully comprehend, I'm with the orignal author, that MVC and the samples are a bit overwhelming when trying to comprehend everything in one sitting, perhaps if there was a sort of cheat sheet to use when applying knowledge or concepts from other frameworks may make learning MVC more bearable for those that find it challenging.

While the feedback is always apprieciated, because if someone complains, it means there is something to improve, on the other hand if you do a little investagation on the author posts, you will find that he is very vocal and compares a lot of stuff to rocket science.

Some samples:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/20313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

Even when things are not rocket science they can still be complicated and require patience to study. Reading more on the topic instead of complaining it is too hard might be a good place to start.

It appears your issues are not with MVC, but Entity Framework. For some of us comfortable writing SQL, Entity Framework adds an undesirable layer of abstraction. Personally, I use Dapper, which just makes using Readers much easier. You still get to write your own SQL. MVC is a pretty simple pattern. It gets a little trickier understanding how to pass data in and out and how to use some of the helper functions effectively, but conceptually it isn't tough.

MVC does not require the use of EF, although the built in user authentication uses it.

Friends, comment with help or positivity, but not with ridicule. The OP does seem to be having concerns with EF, and David’s comment is excellent. https://github.com/aspnet/AspNetCore/issues/7039#issuecomment-457869924

Issues is a place to help. If you want to argue the merits of MVC vs something else, try one of the Internet’s other popular complaint sites.

Hey welcome @LJ9999 I wish more people would ask questions like this.
I'll start of by saying this is merely my opinion so please feel free to agree or disagree with any or all of it.

I totally agree that web/software development is hard. I personally have spent years studying and experimenting to gain the experience that I have. Any time I want to use a new framework or library it is still hard. It requires me to spend more time learning and experimenting again to be comfortable and confident to use it. As I've learnt more and more over the years I genuinely believe I've become better and faster at learning so hence it becomes easier.
Over the years, I think the challenges involved have changed. Some thing have become easier however new challenges have also been introduced. Overall however, I believe it is much easier now compared to when I started. I also think its less of a frustrating experience and I find it to be more enjoyable.
Having said all that, I think as an industry we can always continue to strive for better. I think its questions like this that highlight the challenges we face and inspire the need to continue improving the situation.

I want to be especially careful not advise you on choosing one solution over the other because I don't believe there is enough information for me to do so.
One of the biggest challenges I find with problem solving is identifying the actual problem being solved. It would be very easy to categorise this problem as needing to "build a website" however with so many solutions to choose from to "build a website" any one of them could potentially work. The problem needs to broken down as much as possible because this provides a criteria to evaluate the different solutions against.
Secondly, we all have personal preferences. You are entitled to your own, and no one can tell you what you prefer or feel more comfortable working with. This is entirely based on you.
Also, when others are involved, a team or a company, additional factors may need to be considered such as the teams preferences, as well as the companies policies and strategy.
These are just some of the factors involved that need to be taken into consideration when evaluating different solutions.

One final thing I would like to address is your message. I think it is not specific enough to understand what you are expecting from a response. In my interpretation, there are many different questions to which your are trying to get an answer for, as well as you providing your opinions. These are all valid and useful however when asked and raised together in one github issue, it is difficult to put together a clear and concise answer or begin a discussion to provide you with the answers you seek.
My suggestion to you would be to try again and be more specific with your questions or opinions. Don't worry about opening lots of issues, if they are well written and scoped they would be much better received and you are far more likely to get answers to your questions or directed appropriately.

I hope this response helps in some way. Just know that there are many individuals that are willing to help, however it is your responsibly to make it easy for someone to help you.

@LJ9999 one (hopefully constructive) comment...

From the SQL you posted it's possible that you're using Entity Framework 6. Entity Framework Core (a newer version written from the ground up) has an explicit goal of generating sane, readable SQL that tries to resemble what you'd write yourself - there's a very good chance that if you try that you'll see something more reasonable - give it a try and let us know.

My bottom line criteria is simple... Number of lines of code to implement. More code - more bug risk, greater learning curve, more wasted hours (unless you are a contractor billing by the hour).
I have seen a 8x greater code volume from doing mvc with Javascript framework.. Over old school cshtml pages. And 5x more time.

Beware of those using the phrase "right way"

MVC as a software architecture is more helpful to you in this case.
M is the model, which could be your database, it can respond to requests for information, respond to instructions to change the state of its information, and even to notify observers in event-driven systems when information changes.
V is the view, which effectively provides the user interface element of the application. It'll render data from the model into a form that is suitable for the user interface.
C is the controller, which receives user input and makes calls to model objects or just render the view.

Your choice of tech stack doesn't mean MVC is good or bad, it's just a software architecture.

@shanselman

Friends, comment with help or positivity, but not with ridicule. The OP does seem to be having concerns with EF, and David’s comment is excellent. #7039 (comment)

I completely agree Scott.

It is also understandable that some more experienced users feel strongly about a title that seems to swipe away a great framework and years of hard work by the ASP.NET core team and the community as 'not usable' in a single statement even though that was probably not the intention. I think that probably caused the ridicule.

It might help to change the title to match the actual problem.

We periodically close 'discussion' issues that have not been updated in a long period of time.

We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.