Do you guys think packaging using structs is a bad

Question

Do you guys think packaging using structs is a bad

practice?

for example you have a models package, and inside you have these structs with methods:

User{}.FindAll()
Book{}.FindAll()
...

The other way to do this is to have each of these structs as a separate package inside models package. So:

models/usermodel -> FindAll()
models/bookmodel -> FindAll()

0

29.09.2021

5 ответов

6 просмотров

ㅤ Автор вопроса

Roman Sharkov
why not UserFindAll() ?

The reason I'm attached to the first approach is that you can define relationships on your structs. So for example, user, err := models.User{}.FindById(1) if err != nil { return } books, err := user.Books() if err != nil { return } So on User{} we have these methods that use the current user's id to do a relational query. func (u *User) Books() (books []Book, err error) { // SELECT * FROM user_books WHERE user_id = u.id <--- }

0

29.09.2021

ㅤ Автор вопроса

ㅤ
The reason I'm attached to the first approach is t...

Oh and one thing else, if we use different packaging there will be import cycles

0

29.09.2021

Roman Sharkov

ㅤ
The reason I'm attached to the first approach is t...

I recently use the services package where every service is a subpackage all services have methods like: services.users.Create services.users.GetByID services.users.Restrict services.books.Create services.books.Archive services.books.FindByUserID services.booksearch.Find I try to segregate responsibilities as much as possible every service has Writer and Reader interfaces: package users type Writer interface{ Create(ctx context.Context, id, name string) error Restrict(ctx context.Context, id string, p Permissions) error } type Reader interface { GetByID(context.Context, id string) (User, error) } type ReadWriter interface { Reader Writer } func New(rw ReadWriter) *Service {/*...*/} this way the implementation of a service is abstract and I can thus move it out of the monolith to a separate microservice or mock it for testing. There is also a clear separation of concerns, like for example: The users service keeps track of profiles and permissions, the books service keeps track of books, the booksearch service provides extensive search functionality (uses something like Elastic). Then there's also the gateway service, which is a GraphQL/REST API talking to other services, it's the only publicly available service exposed to the internet as an ingress point. You can have those services in one single executable btw, no need to have actual microservices complicating your deployment. But it's going to be easy to split things off to separate microservices later on.

0

29.09.2021

ㅤ Автор вопроса

Roman Sharkov
I recently use the services package where every se...

That's an interesting way to do it, I'm gonna try a project from scratch with this concept. Thank you

0

29.09.2021

Roman Sharkov · Accepted Answer

Roman Sharkov

why not UserFindAll() ?

0

29.09.2021

Похожие чаты

Do you guys think packaging using structs is a bad

5 ответов

Похожие вопросы