1

I'm developing a C-based software in which I want to use a Model-View-Controller approach, and while I think I quite got into the style's rules, I don't really understand where should I place the methods about connecting to the server (I'm developing a client). One of the cool things of MVC is unlinking the actual logic of the program from the architecture of the machine and system you're working on, but every machine has different ways of managing connections, so I guess model isn't the best place for that. But controller and view should be about visualizing stuff and taking inputs from the user, so it's not really clear where should I put that.

Any advices?

Eärendil Baggins
  • 121
  • 4
  • The controller and model may both be on the server. Or all three on the client. The server connection is not part of anything MVC addresses; it is a separate concern. – Frank Hileman Jun 18 '17 at 22:17

1 Answers1

1

A view is where you put logic that presents the state of what you are modeling.

A model is where you put logic that manages the state of what you are modeling.

A controller is where put logic that seeks to change the state of what you are modeling.

There can be many views and controllers for the same model. A view might talk to a GUI. It might talk to a server. A controller might get input from a GUI. It might get input from a server.

MVC is about focusing on three areas of responsibility. That doesn't mean you can only have three modules.

candied_orange
  • 102,279
  • 24
  • 197
  • 315
  • So is it a logical approach to separate some code in another "view" that talks to the server? Or would it be better, as my software uses quite a lot of system-specific code, libraries using it I've already put in a fourth module called "utils" in order to leave the model clean and portable C only, to include the network connection code in the utils module too? – Eärendil Baggins Jun 18 '17 at 19:01
  • @EärendilBaggins What is the server connection for? If it is to control the controller, it will be associated with that. If it is to serialize the model, it should be in a separate layer. – Frank Hileman Jun 18 '17 at 22:19
  • System specific code belongs in a module called after that system. Putting it in a module called "utils" is asking for it to get mixed in with functions that calculate the area of a circle and objects that do nothing more useful than say "hello world". Always use positive names to organize concepts. Never use names that mean not part of something like "not model", "auxiliary", "extra", "miscellaneous" or "utils". Don't use names that mean I have to guess what's inside. – candied_orange Jun 18 '17 at 22:22
  • @CandiedOrange Oh, nice advice. To be honest our utils folder is just a place where we put some utilities we developed which could be used later, but I guess your idea is better. – Eärendil Baggins Jun 19 '17 at 14:16
  • @FrankHileman it's an exchange of messages between client and server. The data received from the controller needs to be sent to the server. Serialization happens in the "higher level" server functions (not the machine specific ones but those who use them). – Eärendil Baggins Jun 19 '17 at 14:17
  • 1
    Sounds to me like a Service tier which use to be "below" the MVC tier. The MVC component in charge of the communication, IMO is the model. The same way the model access to the DB it can access to the server via servicies. – Laiv Jun 19 '17 at 18:17
  • @Laiv I know MVC is sometimes implemented that way but there are a great many resources that encourage us not to put the DB at the center of our application. The DB can be treated as an IO port the same as the GUI can. The different styles have names. What you describe is called an anemic domain. I'm allowing for a rich domain. This anemic domain only really make sense when the applications only reason for existing is to manipulate the database. – candied_orange Jun 19 '17 at 18:43
  • So in rich domains, which layer (component) plays the role of the interlocutor between MVC and the adjacent tiers? (I have been implementing anemic domains for too long and I'm rusted) – Laiv Jun 19 '17 at 18:48
  • @laiv like I said you can have more than one view and controller. In fact, doing that naturally leads you down a design path to command query separation. Remember, MVC is our oldest and most messed around pattern. Anything that has these three areas of responsibilities separated can justifiably be called MVC. – candied_orange Jun 19 '17 at 19:07
  • So, If I got it right, there could be a view control, let's say (for instance) a button *Send* which triggers a Command, which could be handle by a controller in the charge of sending a message to the server. Am I right? So the model has nothing to do with the remote access. – Laiv Jun 19 '17 at 19:49
  • The model's job is to be the state of the application. In chess it's where the pieces are. In a text editor it's what you've typed. If you're sending it to a server(like I'm about to do)you likely do something like hit the [Add Comment] button. That is sent to some controller that decides if it wants to let us change the state, sends the command through to the model. The model takes that request to post and adds the text that it knows about and sends it to the view which knows which server we're talking to and sends the text to the server. But that's only one of many many many ways to do MVC. – candied_orange Jun 19 '17 at 19:57
  • Hm, so is creating a view and controller for the server connection the best approach, or can we just use a module that's not organized in a view/controller way, but which is still separated from the model? And in the first case, how would code be divided between view and controller since there's nothing "visualized"? – Eärendil Baggins Jun 20 '17 at 00:57
  • Best is subjective. Every solution comes with pro's and con's. Concentrate on what works for your situation. But if you want to see some amazing flexibility at the cost of a little upfront design check out [Clean Architecture](https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) – candied_orange Jun 20 '17 at 01:16