Role of the Controller
The controller acts as the traffic director in an MVC architecture. It receives HTTP requests, calls the appropriate model to retrieve data, and passes the result to a view for rendering a response.
Controller with Go Standard Library
A basic controller can be implemented using Go’s net/http package by accepting a response writer and request. It handles errors manually, retrieves data from the model, and renders the corresponding view, but this approach introduces repetitive boilerplate as the application grows.
Introducing Echo Framework
Echo provides a cleaner structure by wrapping request and response handling inside a single context object. This reduces repetition and offers helper methods for common tasks such as error handling and response formatting.
Refactoring Controllers with Echo
When using Echo, controllers take an Echo context instead of separate request and response objects. Rendering views and returning responses becomes more streamlined through built-in helper methods.
Handling Route Parameters
Echo simplifies extracting path parameters, such as an article ID, directly from the context. The ID is converted to the appropriate numeric type before being passed to the model for database lookup.
Consistent MVC Flow with Abstractions
The overall flow remains the same: controller receives a request, queries the model, and renders a view. Echo enhances this pattern with improved abstractions for routing, middleware integration, and error handling.
Now we have introduced what our model and what our view is.
The final piece we are missing is the controller.
Controllers are like the traffic directors of your app.
They receive incoming requests and then they figure out where to route it and what to return as a response.
This often means calling a model, getting some data and then passing it on to our view.
Now again, the standard library has actually very good support for everything we need when it comes to web development.
This means that we could write a simple controller using just the Go standard library.
And the way we would do that is just to say func and let's say home controller.
This is going to take in our HTTP response.
Writer is going to take in our HTTP requests.
And then inside, let's just say we grab all of our articles.
From our model, models, find articles, we're going to pass the context.
And then if we have an error, we are going to say HTTP error.
And we're going to pass the response writer.
We're going to say something went wrong.
Not really the best error message, but it gets the point across.
And we also need.
A HTTP status code, so let's just say server error and then just a negative return here.
But if nothing goes wrong, then we simply call our views of use home.
We pass the articles, then we call render because this is a method exposed by a temple where we can pass the context and then again, the response writer.
So.
So here the controller function home home controller takes in a request as the model for some data, and then it went just the appropriate view.
This works and you could totally continue doing this, but as your app grows many managing all these handlers using the the net slash HTTP packets can get quite repetitive.
You often need a bit of a boilerplate for error handling.
So if you want to do this, then you need to do a little bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more, but if you want to do this, then you need a bit more.
ECHO gives us a clean and structured way to write controllers, but also write routes, as you'll see in one of the upcoming episodes.
If we were to express this controller, but using ECHO instead, we would get rid of these two arguments and simply just have one argument, which is going to be the ECHO context, and we need to add this to our go.mod file.
If we were to express this controller, but using ECHO instead, we would get rid of these two arguments and simply just have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we need to have one argument, which is going to be the ECHO context, and we get rid of these two arguments.
For example, let's say returning some HTML, or we could return JSON, but for now, let's just return the error.
Finally, we can say return views home and just update this to use the request, and then the response.
There we go, and we have all the arguments that Temple expects.
So, ECHO provides us with a lot of helper methods.
It removes a lot of the repetitiveness through the ECHO context.
Now, let me just do this, but for the article views, we can render both the home page, but also the article page.
All right, and to add the article controller, we can just grab everything we have here,
and let's just call it, actually, let's just call it this one article and expose it,
because we're already in the controller package, and do the same.
For home here, there we go.
Now, remember when we added the anchor tag in the last episode about views,
so that we could actually click an article and be passed in the article's ID.
Well, the way we can grab that in the controller is to use a helper method from ECHO.
So, we're going to say ID or error, and we're going to receive a string that we technically need to be in 64.
So, we're going to wrap all of this in a string.
The string conversion, say, okay, there we go, and it's imported.
So, this simply just passes, accepts a string, and then returns an integer.
And then we can say cparam, because it's going to be a parameter we're going to pass.
It's going to be called ID, and this will make a bit more sense when we get to the router and routes layer.
But for now, just stick with me.
This will get passed through the view, right?
Again, let's just return an error if there is one.
And now we need to call findArticle.
That needs to get our ID in the form of an int64.
So, let's just wrap our ID in this.
And now we are not rendering home anymore.
We are rendering article.
And let's just call this one article.
Again, article.
So, here we are using...
One of the helper methods exposed by Echo to easily extract the ID that gets passed as a route parameter.
Then we convert it to our integer.
And then finally, we convert it to an int64 so that our model can go into the database and look up this article.
So, notice how the structure is very similar.
The controller takes in the request, it calls some models, and then passes the results onto the view.
However, Echo...
Gives us some nice abstractions.
We get the request and response wrapped in the Echo context.
We have an easier way to work with something like path parameters, but could also be curious things.
It plays very nicely with middleware, with error handling, and also routing, which we will see in one of the upcoming episodes.
