As a C++ developer from the 90s during the great OOP wars, I put high value to OOP as a basis for hiring new C# developers into the company.
However, there are plenty of frameworks today like ASP.NET MVC that handles most of the OOP heavy lifting. Programmers without deep knowledge of OOP can just as easily follow the paradigm and still be able to complete their projects. OOP may not be as compelling as it was before for us application developers, especially with a framework like MVC.
I can see a few instance where OOP will be really handy, like for example developing a workflow type of a project. Or those with state-machine requirements. But really, most projects that really come by (at least to us here anyway) are just CRUD functionalities.
Below is my list when hiring. Is it fair to have OOP there as the number one item?
- OOP and Design
- Server side programming: C#, ASP.NET MVC and EF
- Client side programming: JQuery, CSS, HTML, etc.
- Database design
Best Answer
When I was learning MVC in PHP, I often thought that "this OO stuff is just functions wrapped by classes", especially since I was used to a procedural style of coding. But then I got more and more into researching design patterns, proper encapsulation, decoupling and general theory behind OOP.
I can say that understanding the OOP principles in the context of MVC really made a difference in the Model part of the app. While the controllers are still pretty much already laid out and all you need to do is fill the action methods with the proper code, and views are just html with some code here and there, the model is where knowledge of OO principles shows. When you have anything more than a dead simple CRUD app, it involves planning the domain classes. Then you throw in an ORM like EF to take care of persistence, and add some repositories to decouple from the EF implementation. Then you implement a unit-of-work to do persistence for each request. Then you throw in a DI container like Unity, to keep all of this nicely decoupled, mostly to allow for proper testing.
The "application" is in essence the domain model, with the entity classes, services and repositories, and if this part is done right, it almost makes no difference what kind of UI you put on top of it, be it an MVC app which serves pages, or some REST app which will send JSON to a mobile app, or a desktop app. A well designed Model can be reused across different applications.
Also, knowing OO principles will make it easier to understand how the MVC thing works in the first place, and help clear out some of the "magic" that might be happening under the covers, and it will make it easier to switch languages if necessary (and if the other language is also object-oriented).
In conclusion, I'd say yes, OOP and design is essential.