Is it good practice to use AppDelegate for data manipulation and Handling?

Question

I am making an object of AppDelegate and using it throughout my program, and I have declared all setters and getters, and also insert, select, delete, update queries of database in it.

I want to ask that is it a good practice to do so, if yes, then how, and if no then why it is not a good practice?

I hope my question is clear, please ask relating questions if you have any.

Demonology

Answer 1

It's not a good strategy to turn your AppDelegate into a "big ball of mud" that contains a million methods and properties (although it might be tempting).

A better and more object oriented approach to section off bits of functionality into well-designed objects -- for example you might have a class DatabaseManager which handles all database interactions. You might then have bits of your app which need the DatabaseManager ask the app delegate instance for a reference to a DatabaseManager.

Alternatively, you can pass around a reference to the DatabaseManager to the parts of the app that need it. This last approach does however cause more 'interface pollution', where you have to modify interfaces in lots of places in order to pass in the DatabaseManager.

And yet another alternative would be to effectively make your DatabaseManager itself be a 'singleton' -- whereby an instance of it is accessed via a class method on the class. Singletons that work in this way are often frowned upon, and usually for good reasons (makes testing harder, that sort of thing). I tend to avoid having objects have their 'singleton' nature baked right into the object -- I prefer, if I need that sort of thing, to have a known point of access (a kind of 'factory' if you like) where you can go to obtain a shared instance.

Seemaseeming

Answer 2

I think the best way would be creating a global singleton class instead of handling in the Appdelegate.

Declare all you setters and getters there and using the singleton object handle all around your project. See this link how to create singleton class

For Database, create a DataAccessLayerClass. whenever you want to execute any queries access this class. This class methods should have inputs as your data and will create the queries and will execute that query and return the data.

Ph

The singleton pattern you mention - where an object has singleton nature 'baked in' -- is quite restrictive. What if you later want to have two database manager objects (because you connect to two databases)? What if you write tests that require more than one instance to exist for the purpose of the tests? It's more flexible to provide a factory of some sort that hands out a configured shared singleton instance. Just my opinions. – Seemaseeming

And another problem: good designs often involves passing in configuration info into a database manager (or whatever), rather than it configuring itself (again for reasons of testing etc). But this becomes tricky if all your code asks the singleton object itself for its shared instance, since all your calls to getInstance must pass in the configuration info in case it is needed. – Seemaseeming

Answer 3

It's all about complexity and your feelings. You must like your solution ;-)

I obviously do this in another way - I've got singleton, which does handle all my common database things. I'm trying to keep application delegate as simple as possible. It's better for code sharing, etc.

Merlon

And other people have to like his solution later if they're working on the same code :) – Seemaseeming