Where to create your structs?

Getting Help
1

This is more of a conceptual question vs a coding question.

As I’m reading about MVC is calls out that all your “data” constructs should be in the model. To me this seems that if I have a slice of structs that’s going to be populated from a database, that struct should be in the model but exports. You would then pull that struct into your view later in order to present it via your templates.

However… I’ve seen quite a few videos on pluralsite where they create the struct that will be presented to the template in the view. This seems a bit counter intuitive to me if the model is supposed to be handling all “data” aspects of the code. Wouldn’t we consider structs a key element of data?

Thank you kindly

2

You can do both. Having your data structures in your model sounds fine (just please don’t call it model – for the same reason you don’t call your child “offspring”).

Using a map, a struct, even an anonymous struct to pass data into a template is perfectly fine, it doesn’t need to be exported or even given a name; for example

t.Execute(w, struct{
   Id int
   FirstName, LastName string
   DateOfBirth: time.Time
} {
   Id: 42,
   FirstName: "Gordon",
   LastName: "Gopher",
   DateOfBirth: time.Now().Add(-7000 * time.Hour)
})
1 Like
3

Non-native speaker here.

Why not model? :thinking: I don’t get the “child-offspring” analogy :flushed:

4

My rule of thumb is a packages name should be a one world elevator pitch for what it provides, not what it contains.

Models is a tricky one, but consider what would happen if you combined two projects together, both with their own models directory, suddenly something which could be descriptive “this provides the projects models”, becomes useless without additional qualifications – meaning you end up renaming the import.

As usual, my recommendation is to avoid this level of taxonomy, rather than creating a package called models, with one type per file (I’m assuming) create one file called models, and place that in a package that also includes a controllers.go and views.go, then the name of THAT package becomes very descriptive, it provides your product.

4 Likes
5

Thanks for explaining. I was completely on the wrong track, thinking that using the word “model” has some negative connotation in itself, but now it is clear to me.

It is true that package naming gets a lot less attention than it deserves. Packages named “utils” are a typical sign of that.

2 Likes
6

Models is an interesting example that somewhat breaks the rule. Model, as in the m in MVC, could indeed fulfil the “explain what your packages provides in one word” sniff test whereas many other names do not, util/base/common being great examples of bad names.

But, stepping back and looking at a package in th context of a whole program, model becomes poblematic. I cited on example where what is a good idea on the small, blows up as the program grows and changes in response to changing business circumstances. I worked on a project recently where each major piece of functionality had its own “testing” child package (this isn’t really a thing, but I didn’t want to say sub package as that isn’t a thing either). This pattern worked wonderfully for giving us a place to put test helpers for the package under test. However, as these were by definition functional tests, as thy were define in a separate package, the temptation to reuse them to constuct and test higher level functionality wslas overwhelming and lead quickly to many test packages importing many different “testing” packages, this requiring us to rename their imports to avoid conflict.

So I’d like to give a second piece of advice, in addition to my first; a packages name should be reasonably unique within the final program. There may be many http routers, r logging packages, and so forth that exist inside the whole go ecosystem, but within one project, you should import at most, one of those.

4 Likes
7

Ok I now understand what you mean, thanks for the clarification. It seems there are a lot of tutorials out there than pass on bad practices. I used to do PHP development about 10 years ago, so I’m not “new” to programming, but the whole MVC concept is new, as well as the Go language.

Your comments about “model” not being named “model” makes perfect sense, I wish introductory tutorials covered things like this.

Thanks!

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.