I am developing a Cocoa based application that will make several calls to a Postgres database (using PGSQLKit) over the course of a user’s transaction. The application is a kiosk of sorts.
What I’d like to know is the proper way to make database calls throughout the application. In the spirit of MVC, I know I should create objects for the data that is returned from the database (which I plan on doing) and then work with those objects. Where I need clarification is where I should place my database calls.
Basically it comes down to these questions I have:
-In order to interact with the database, should I create a separate database controller class that would make database calls? I feel making database calls directly from a view controller would not be appropriate.
-Assuming I create a database controller, should my view controllers trigger the database controller class and make DB calls that way?
-When the application loads, should I make a connection to the datase through the database controller and close it when the user’s transaction is complete? I’ll be making several calls throughout the transaction so I don’t think i should close the connection each time.
Correct. In some cases you may even have another layer of model objects on top of the database controller. Most of the app shouldn’t care that the data is stored in a Postgres database rather than some other way.
Generally yes. Your view controllers will observe the model and tell the model when they need data. The model will let observers (including view controllers, though the model doesn’t care who they are) know when relevant data becomes available or changes.
That is an internal detail to the database controller. Generally this kind of object would maintain a long-lived connection. Usually that connection is made the first time the model is asked for data that it needs from the database rather than “at application start.”