On Monday, 29 May 2017 23:44:32 UTC+3, Darko Luketic wrote:
>
> Humm.. I wrote a reply but it seems it only reached Justin and not this 
> group.
> Also I have not received other replies via email.
>
> Ok...
>
> Ayan, no that's alright it was storage.UserModelInterface
> and I know what you're all saying but I saw no other way to make them type 
> agnostic and I'm a fan of explicitly calling things what they are 
> especially when I'm experimenting.
> And it's not really the point.
>
> I tried Justin's idea or rather the idea that resulted because of Justin's 
> reply
> and
>
> https://github.com/dalu/forum/tree/6bb47c27c606b30f91412b48b1af561abe0f5558/server/storage/mongo/service
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdalu%2Fforum%2Ftree%2F6bb47c27c606b30f91412b48b1af561abe0f5558%2Fserver%2Fstorage%2Fmongo%2Fservice&sa=D&sntz=1&usg=AFQjCNFvqEzOG34KzTMCBCHiNe0WZN9t7g>
> it's not thread safe
>
> because it operates on the passed instance of the concrete model.
> In 
> https://github.com/dalu/forum/blob/6bb47c27c606b30f91412b48b1af561abe0f5558/server/storage/mongo/service/user_test.go#L24
>  
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdalu%2Fforum%2Fblob%2F6bb47c27c606b30f91412b48b1af561abe0f5558%2Fserver%2Fstorage%2Fmongo%2Fservice%2Fuser_test.go%23L24&sa=D&sntz=1&usg=AFQjCNE8HOw686aATWqnRH8FlekwDeolLA>
> I initialize a service with a new user storage and a pointer to a 
> (mongo)model.User
> In 
> https://github.com/dalu/forum/blob/6bb47c27c606b30f91412b48b1af561abe0f5558/server/storage/mongo/service/user.go#L21
> I copy the pointer for the lack of better means to create a new copy, 
> shallow copy (a := *b) doesn't work because it's an interface
>
> So I think I'll just call it quits and go concrete up to the service level.
> Yeah Egon ID is the lowest common denominator (that brainfart moment on 
> reddit was me ;) ).
>

I completely missed that :D, Would have loved to see it.
 

> And it would probably work but I'm not risking it for this one :)
>

With regards to the error, others already answered it, so I didn't bother 
with it... and answered your last question.

I know it may seem like I'm doing minor nitpicking w.r.t. value, naming and 
organization; but after 4+ years and researching the subject has lead to me 
that,
Once you properly understand those, many of the other problems just 
disappear... or the solution to them becomes obvious.

The organization I showed isn't without precedent... sure, I can understand 
if you decide not to go with that structure; *often, the devil you know, 
will be faster to develop with.*

Naming wasn't bad, it was stuttery, but not bad. The main problem was 
package organization.

On these topics:
* 
http://www.carlopescio.com/2011/04/your-coding-conventions-are-hurting-you.html
* https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1
* https://en.wikipedia.org/wiki/Form_follows_function
* https://github.com/marcusolsson/goddd
* 
https://forum.golangbridge.org/t/comparing-the-structure-of-web-applications/1198
* https://vimeo.com/108441214

For bson I can use the getter/setter interfaces but idk if there's 
> something like it for other databases, so I'll just go abstract (or 
> interface) on the service level.
>
And the storage/repository and model will be concrete.
> UserService will be an interface
> ThreadService will be an interface and so on
> and there will be MongoUserService PostgresUserService and so on.
> and implementing new databases will be a pain in the butt.
> But that's Go for you :)
>
> Thanks for feedback all.
>

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

Reply via email to