Closed vanhtuan0409 closed 6 years ago
Thanks for the reaching out, I'm very open to discuss the better practice. I think you describe 2 issue: Q1, r u means the the Persistent model was unnecessary?In my view, business model should not coupling with SQL sentences or the object level cache issue, so how would you write the codes without gorm? BTW, many codes here are reusable. Q2, The purpose of this project was that showing a conciseness practice of using framework, such as data binding and param dealing, not how to improve the throughput. Of course, api like Article Feed
could use Elastic Search, auth model could save in Redis, the performance will be totally different, but that's another topic.
Feel free to discuss:)
Sorry, my English is very bad. I will try to explain my concern again. I think we should aim for absolute separation of Business model and Persistent model.
func (u UserModel) following(v UserModel) error {
db := common.GetDB()
var follow FollowModel
err := db.FirstOrCreate(&follow, &FollowModel{
FollowingID: v.ID,
FollowedByID: u.ID,
}).Error
return err
}
With this function, UserModel was coupled with a specific database implementation and it will be hard to test this function without running a real SQL database.
With ORM, your users/router.go
become very clean and I love it. But I afraid with ORM, you cannot separate Business Model and database implementation completely. How do you think about using repository pattern
with an interface?
Alright, those kind of code only appears in the dealing of relationships(one2one,one2many,many2many). Normal objects might need modify some fields without committing a transaction while most relationships could be modified right now, so I didn't separate them.
How to save the relationships are truely related to database such as MongoDB using List type. BTW, Golang was not object-oriented language, do we need to separate a very pure object without persistent?
As for testing, I just used a test DB for integration tests like the Django framework, mocking the datas in the real test database
. It's not friendly to writing unit tests with relationships.
@wangzitian0 tks for your reply 👍 I learnt a lot from your project
Just my concern, it is considered bad practice when you use the same Persistent Model for Business Model. Also, I saw some pieces of logic was implemented by database query (Article Feed)