Hi Karan, >I don't have a background in Java/C#[...]
This is actually good, there is less for you to "unlearn" If you don't want to pass parameters to create a user, like passing the userID, name, etc, because it "seems wrong/verbose", then don't worry about it. In Go (any I apply this to other languages too), it's better to be explicit with the parameters that your functions or methods need, vs being "clever" and try to hide the fact that to create a models.User instance, you need 10 pieces of data. When I write Go code or when I do code review in our company, I ask questions like: * Will future junior devs have a hard time reading/understanding the code? If the answer is yes, then I need to rewrite it, code should be easy to follow (most of the time, of course there are going to be exceptions, but try to write simple code as much as you can) * If I get a call at 3am to debug our app, will it take me hours to remember why this code is written like this? Again, the idea is, code should be essy to follow, no hiding and no adding abstractions just because people do that in Java/etc P.S. Of course I don't want to even get a 3am call :) Hope this helps. Diego On Wednesday, August 19, 2020 at 12:39:27 PM UTC-4 Karan Singh wrote: > I am having a bit of difficulty in designing my Go code. > > I'll try to demonstrate things with a very simple example of adding a new > user to the database. I have 3 major components in this example: a handler, > a service and a dao layer. > > 1. > > My Handler is only doing one thing: Calling a service. > 2. > > The service is managing all the business logic and then calling the > DAO to interact with the database. > 3. > > The DAO also has only responsibility: Storing in the database. > > Also, just for context I am making GraphQL(gqlgen) requests to interact > with my ElasticSearch(olivere/elastic) database, but that shouldn't affect > the design too much. > > MY CODE: > > *https://play.golang.org/p/Wm9qubLJIGM > <https://play.golang.org/p/Wm9qubLJIGM>* > > I have read a lot of posts about using structs/interfaces to handle the > service layer and DAO layer, but I am unable to implement the same in my > usecase. > > I don't have a background in Java/C# so I'm not well versed with OOP > Principles but I did read a lot on MVC based on other answers. > > My code works for now, but is it bad code? > > I don't want to be passing parameters from one function to another. Is > there a way to that with receivers on methods? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3c15bd16-25d4-46c8-a754-2b33eda23faen%40googlegroups.com.
