Good day. I am a novice programmer, so there may be stupid questions.
I am doing a project on ASP.MVC, a question arises related to the architecture of the project.
I have a ViewModel class, which contains the data with which the controller will work and which will be displayed on the Internet page. There is a ViewModelBuilder class that converts a database object to a ViewModel and vice versa.
I need to accept the string entered by the user, process it, extract the missing data from the Internet and form the ViewModel.
The question arose in which class to write the methods that process the input data (this is not validation), pull the missing data into their networks and form the ViewModel.

I have 3 options:
- To controller
- In ViewModel
- In a separate extension class to the ViewModel.
I don’t like the idea of ​​a controller, since these methods are still nothing to do with BusinessLayer and in the controller.
ViewModel for some reason also do not want to load these methods. It seems that they will look logical in this class, but for some reason at the level of intuition, I don’t like this idea.
I am afraid to bring them to the extension class for performance.

Question: where is it correct from the point of view of architecture and following the principles of MVC to place the methods that process the string entered by the user, convert it, pull data out of the network and convert it to write to the ViewModel properties.

  • Why should an extension to an extension class affect performance? - Grundy
  • Still, a method of another class. I am not so well versed in low-level processes to clearly understand this issue. - foxhound
  • one
    And do not be afraid. Fear comes from ignorance. Read how extension methods are implemented, this is just syntactic sugar. And, really, it is ridiculous to fear a drop in performance on the calls of extension methods when you have reading from the database and Internet parameters: these operations are tens and hundreds of times slower. You are afraid, but there is a saving on matches. - AK ♦
  • @AK, it is worth making out the answer :-) - Grundy
  • one
    @Grundy in the subway uncomfortable writing code. I arrived, wondered if I had anything else to add - and yes, it turned out to be a full answer. - AK ♦

1 answer 1

I see in your question two layers.

The first is about the performance of extension methods. In fact, this is just syntactic sugar for calling a static method . When the compiler encounters an instruction called an extension, it generates the IL code calling the static class:

void Main() { var message = "Hello Extension Methods"; int counter1 = message.WordCount(); int counter2 = MyExtensions.WordCount(message); } // Define other methods and classes here public static class MyExtensions { public static int WordCount(this String str) { return str.Split(new char[] { ' ', '.', '?' }, StringSplitOptions.RemoveEmptyEntries).Length; } }

IL-code is the same in both cases:

IL for static

You are worried about a possible drop in performance. But in your application there is a reading from the database and parsing the Internet - much longer operations, tens and hundreds of times. You are afraid of losing, but there is a saving on matches.

The second layer of the question is where to post correctly. I would like to answer you in terms of DDD (Domain-driven design): where you have a layer called the subject area.

Here you have the actual description of this class:

I need to accept the string entered by the user, process it (and this is not validation), extract the missing data from the Internet and form the ViewModel.

I do not know your subject area, so I can offer to call this class * Manager. This is not very correct from the point of DDD and the approach can be criticized, but architecturally - movement in a more correct direction, is any better than placing a method on a controller (TTUK architecture (Thick, stupid, ugly controller)) and moreover putting [business logic] into the layer representation.

  • Thank you, figured out - foxhound
  • I see no reason to create a separate question, the principle is the same as that of the author of this one, please just clarify whether I understood the essence of the problem ... It turns out that to process user data in MVC it ​​is best to create a separate class, or several additional classes responsible for different tasks, and for some calculations with user data or some logical operations, debit credit, etc., etc., call the methods or functions of these additional classes from the controller. In principle, as I could, I asked ... Also while I monitor this topic and try a little ... - SergeyE
  • @Eikhner "Processing user data" - is that validation or business logic? The question you may have is very far from resolved in this problem. For now, I can simply say from general considerations that "controllers should be thin, models should be thick, and views should be stupid" (C) - AK ♦
  • @AK Not validation, "for some calculations with user data or some logical operations, debit credit, etc., etc." - SergeyE
  • @Eikhner In the domain definitely. There are many examples of bank accounts in the book by Eric Evans. - AK ♦