FAQ
Hello, guys. I need a peace of advice about the better way of organising my
code in Golang web application.

In my application I use Gorilla mux package to map requests to handlers.
Handlers' logic sometimes needs to use some kind of "Service" object
(structure).
For example:

I don't like writing manually sql or other types of query to database from
my handlers.
I prefer to use Repository pattern. For example, I have UserRepository
type, which implements methods like: getUserById, saveUser, deleteUser,
userExists and so on.
So I don't need to write my queries, I can just use my UserRepository to
create all theese operations. Also, it saves me from dublicating query
requests in different parts of application.

The question is: what is the best way to store these "Service" structures?

The first idea was to store them in packages.
So I will have userrepository package, which will have all these methods.
So when I need to check if user exists with this login, I can just import
my "userrepository" and call userrepository.userExists(login)

But then I got a problem with testing packages / structures, which rely on
my userrepository.
For example I have another service (let's call it UserService) which has
method register(login, password)
Inside the register method I use my userrepository to check if user exists.
And if it does not, I save it to database (again with userrepository
"saveUser" method).
So in my test, when I am testing register method, I need to "mock" my
userrepository. But it's impossible with such an approach.

Then I got another idea.

I can store all my repositories as types in my repository package.

type UserRepository struct {
}

func (userRepository *UserRepository) userExists(login string) {
// Logic...
}

Also I can create an interface UserRepositoryI so that my UserService could
store an object of type, which implements my UserRepositoryI interface.
With this approach I can mock default UserRepository in my test (replace it
with another one, for testing purposes).

Is this approach valid?

And another one question.
I don't want to create new UserRepository object each time I need it.
Is it a good practice to create an exemplar of UserRepository in one of
repository package files and to implement method
repository.GetUserRepository()?
So each time I need my UserRepository I will get the initialized one
instead of creating a new object?

So. The main questions of this topic are:
1. Is it a good idea to store types like UserRepository with an it's
Interface in a separate file (instead of call these methods from
userrepository package directly)?
2. Is it a good idea to create an UserRepository exemplar in the repository
package on application start and every time I need it - to acces it with my
GetUserRepository method defined in repository package?

Sorry for such a long post. Trying to explain my problem as good as I can :)
Just never saw this approach in other people's codes.

Thank you for help.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Meta keule at Aug 8, 2014 at 11:34 am
    You could make your repositories different packages with unit tests and
    make a per request context that is shared between your http.Handlers.

    That context could have per request and global data and can easily be
    mocked.

    To see how such a context can be created and used with various middlewares
    and
    http.Handlers and how a middleware stack can be created that has the context
    injected and shared, see my middleware library at

    https://godoc.org/github.com/go-on/wrap

    Cheers,
    Benny

    Am Freitag, 8. August 2014 12:42:55 UTC+2 schrieb dmp...@gmail.com:
    Hello, guys. I need a peace of advice about the better way of organising
    my code in Golang web application.

    In my application I use Gorilla mux package to map requests to handlers.
    Handlers' logic sometimes needs to use some kind of "Service" object
    (structure).
    For example:

    I don't like writing manually sql or other types of query to database from
    my handlers.
    I prefer to use Repository pattern. For example, I have UserRepository
    type, which implements methods like: getUserById, saveUser, deleteUser,
    userExists and so on.
    So I don't need to write my queries, I can just use my UserRepository to
    create all theese operations. Also, it saves me from dublicating query
    requests in different parts of application.

    The question is: what is the best way to store these "Service" structures?

    The first idea was to store them in packages.
    So I will have userrepository package, which will have all these methods.
    So when I need to check if user exists with this login, I can just import
    my "userrepository" and call userrepository.userExists(login)

    But then I got a problem with testing packages / structures, which rely on
    my userrepository.
    For example I have another service (let's call it UserService) which has
    method register(login, password)
    Inside the register method I use my userrepository to check if user
    exists. And if it does not, I save it to database (again with
    userrepository "saveUser" method).
    So in my test, when I am testing register method, I need to "mock" my
    userrepository. But it's impossible with such an approach.

    Then I got another idea.

    I can store all my repositories as types in my repository package.

    type UserRepository struct {
    }

    func (userRepository *UserRepository) userExists(login string) {
    // Logic...
    }

    Also I can create an interface UserRepositoryI so that my UserService
    could store an object of type, which implements my UserRepositoryI
    interface.
    With this approach I can mock default UserRepository in my test (replace
    it with another one, for testing purposes).

    Is this approach valid?

    And another one question.
    I don't want to create new UserRepository object each time I need it.
    Is it a good practice to create an exemplar of UserRepository in one of
    repository package files and to implement method
    repository.GetUserRepository()?
    So each time I need my UserRepository I will get the initialized one
    instead of creating a new object?

    So. The main questions of this topic are:
    1. Is it a good idea to store types like UserRepository with an it's
    Interface in a separate file (instead of call these methods from
    userrepository package directly)?
    2. Is it a good idea to create an UserRepository exemplar in the
    repository package on application start and every time I need it - to acces
    it with my GetUserRepository method defined in repository package?

    Sorry for such a long post. Trying to explain my problem as good as I can
    :)
    Just never saw this approach in other people's codes.

    Thank you for help.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Shawn Milochik at Aug 8, 2014 at 11:45 am
    I think the answers in this thread are applicable to your question as well:
    https://groups.google.com/d/topic/golang-nuts/z8RukDLPQtk/discussion

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedAug 8, '14 at 10:42a
activeAug 8, '14 at 11:45a
posts3
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase