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 qu

Answer 1

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.

Answer 2

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.

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.