Thanks Dave.
I hear you about models not being their own package. If I read you
correctly, and taking it to the extreme, all files in a micro-service
belong in the same package, possibly bar 'main'.
If all database access is related to the same 'problem area', it all
belongs in the same package as the controllers (assuming it's a MVC-like
arrangement, although in most of these services the M is actually entirely
SQL, and the C consists of SQL code, but that's a whole other thing).
If the models and controllers solved another problem area, they should be a
different micro-service all together.
The model package (not models) is the M in MVC, it contains the models as
stored, but also contains the database queries to fetch them, and possibly
validate them if that is required.
It does not contain, for example, API calls to third party services, or any
ability to parse the http.Request
Should those three not be separate packages?
- Our model, stored wherever it is stored, with the functions to actually
access it
- Other API models, one each (e.g. a salesforce package), with the
functions to connect to, consume, handle errors etc
- HTTP Routing, parsing etc
Or:
/accounts.go:
package accounts
struct Account
func GetAccount() (*Account, error)
/cmd/server/server.go
package main
http.HandleFunc('/account', ...)
import accounts elsewhere, you have the stutter of accounts.Account, so it
could be accounts.Postgres, accounts.Salesforce, accounts.API - which may
work outside of the package, but inside that's very confusing.
I also don't want to call my package 'github.com/org/accounts' - that's
just rude to other developers in the org, AND, it's the accounts service,
where should I put the client, if I were to provide one?
Is there a good, idiomatic example of a micro-service repo out there?
On Monday, April 3, 2017 at 5:14:28 PM UTC-4, Dave Cheney wrote:
>
> I've always argued that a package's name is a one word elevator pitch for
> what it provides--not what it contains.
>
> Package models fails this tests because it enumerates the contents of the
> package.
>
> You could argue that this also provides the models for your project, but
> think about what happens when your models package and a models package from
> another part of your program need to be imported in the same package.
>
> In this situation my advice is to rename the models package, models.go and
> move the file into the package that relies on it.
>
> Dave
>
>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
