Already, probably, three times I get close to ASP.NET MVC. After ten years with ASP.NET WebForms, it is a little difficult to switch to MVC technology, since there are so many differences that it is rather easier to list what these technologies have in common – except perhaps the .NET Framework libraries. I will not write here – is it better or worse MVC than WebForms, it’s just that they are both good, and you can build a good application on both technologies. I will also keep my thoughts on the need for TDD to myself, although I have them.
And now I will talk about the most common task – the usual work with data: viewing a list of records in a tabular form, adding, changing and deleting data (CRUD operations). However, in almost all books and in many solutions on the Internet for ASP.NET MVC, for some reason, the option is considered exclusively through ORM (Object Relation Mapping): either Entity Framework (EF) or LINQ for SQL. The technologies are excellent, there is no dispute, finally the programmer may not understand how this very relational DBMS (which he most likely uses) generally works, and even SQL, in theory, is no longer necessary to know: the gasket in the form of EF and connectors for the DBMS will figure it out among themselves. “This is happiness – there is none more beautiful.” But those programmers who are not afraid of working directly with the database through the ADO.NET mechanism often do not understand where to start in ASP.NET MVC and whether it is necessary.
Plus, for me, for example, in the beginning, the lack of a convenient component for displaying data in a grid table caused a wild break. It is understood that the developer himself must implement all this or take something suitable in the package manager. If you, like me, were satisfied with the GridView component in ASP.NET WebForms more than, then for MVC it is difficult to find something more or less comparable, except that Grid.mvc. But my trust in such components is not enough to be used for a fairly large project. In the case of their use, the programmer begins to depend on another developer who, firstly, does not know how he wrote this component (is it high quality?), And, secondly, it is not known when and how he will finalize it. Sometimes it seems even possible to extend the component and cut further, but, in the case of its completion by the developer, we are forced to either shovel our code again, or freeze the update of the component at a certain version. And if the developer fixes any vulnerability, you still have to upgrade to the new version. Even the transition to new versions of the MySQL connector causes certain problems, although a large company develops it, but what about the numerous “bicycles” in the Nuget package manager?
