You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not too crazy about the syntax of dealing with the database. To me it seems a bit cumbersome to need to manually get an instance of a database everytime you want to do something with a model.
I understand the advantages, it just seems like a case of letting testing considerations define the api. Possibly, I'm not to convinced either that models exist long enough in a typical stateless web app to really be weighed down. If you compare your couchrest sample wiki to the the couchpotato one, it seems like a lot of extra code to do the same thing.
So one idea... since the model is already decoupled from the database, would it make sense to have the save method on the model be responsible for getting an instance of the database right before save, and have it do something like db.save(self). Then loose the reference to the database when it's done.
That way, testing remains decoupled, but we don't have so much of the PHP reminiscent syntax. I know I am probably being picky here, but the model.save idiom in the ruby world is so beloved, I think it may be hard to deviate so much. I may be wrong however.
The text was updated successfully, but these errors were encountered:
I'm not too crazy about the syntax of dealing with the database. To me it seems a bit cumbersome to need to manually get an instance of a database everytime you want to do something with a model.
the default instance is saved in CouchPotato.database and you are encouraged to put your instances into variables as well. for rails apps for example i usualy create a database method in my application controller that return a database instance so in my actions all i have to do is database.view or whatever.
how would a model's save method get access to a database instance?
I'm not too crazy about the syntax of dealing with the database. To me it seems a bit cumbersome to need to manually get an instance of a database everytime you want to do something with a model.
I understand the advantages, it just seems like a case of letting testing considerations define the api. Possibly, I'm not to convinced either that models exist long enough in a typical stateless web app to really be weighed down. If you compare your couchrest sample wiki to the the couchpotato one, it seems like a lot of extra code to do the same thing.
So one idea... since the model is already decoupled from the database, would it make sense to have the save method on the model be responsible for getting an instance of the database right before save, and have it do something like db.save(self). Then loose the reference to the database when it's done.
That way, testing remains decoupled, but we don't have so much of the PHP reminiscent syntax. I know I am probably being picky here, but the model.save idiom in the ruby world is so beloved, I think it may be hard to deviate so much. I may be wrong however.
The text was updated successfully, but these errors were encountered: