Я занимаюсь разработкой приложения для iPhone и являюсь новичком в Objective-C, а также в SQLite. При этом я изо всех сил пытался разработать практическое решение для управления данными, которое достойно существующего. Любая помощь будет принята с благодарностью.
Вот сделка:
Большая часть данных, с которыми взаимодействует мое приложение, хранится в пяти таблицах в локальной базе данных SQLite. Каждая таблица имеет соответствующий класс, который обрабатывает инициализацию, гидратацию, дегидратацию, удаление и т. Д. Для каждого объекта / строки в соответствующей таблице. Всякий раз, когда приложение загружается, оно заполняет пять NSMutableArrays (по одному для каждого типа объекта). В дополнение к первичному ключу каждый экземпляр объекта всегда имеет доступный атрибут ID, независимо от состояния гидратации. В большинстве случаев это UUID, на который я могу легко ссылаться.
Раньше, несколько дней назад, я просто обращался к объектам через эти массивы, отслеживая их UUID. Затем я приступил бы к гидратации / обезвоживанию их по мере необходимости. Тем не менее, некоторые из объектов, которые я имею, также поддерживают свои собственные массивы, которые ссылаются на UUID других объектов. В случае, если я должен отследить один из этих «дочерних» объектов через его UUID, это становится немного сложнее.
Чтобы избежать необходимости перечислять один из ранее упомянутых массивов для поиска UUID «родительского» объекта, а затем переходить к поиску UUID «дочернего» объекта, я добавил DataController с одноэлементным экземпляром, чтобы упростить процесс. .
Я надеялся, что DataController сможет предоставить единую точку доступа к локальной базе данных и упростить ситуацию, но я не уверен, что это так. По сути, я создал несколько NSMutableDicationaries. Всякий раз, когда DataController инициализируется, он перечисляет каждый из ранее упомянутых NSMutableArrays, поддерживаемых в делегате приложения, и создает пару ключ / значение в соответствующем словаре, используя данный объект в качестве значения и его UUID в качестве ключа.
Затем DataController предоставляет процедуры, которые позволяют клиенту вызывать UUID требуемого объекта для получения ссылки на фактический объект. Всякий раз, когда это запрос объекта, DataController автоматически гидратирует рассматриваемый объект и затем возвращает его. Я сделал это, потому что хотел взять контроль над увлажнением рук клиента, чтобы предотвратить обезвоживание объекта, на который ссылаются несколько раз.
Я понимаю, что в большинстве случаев я мог просто сделать изменяемую копию объекта, а затем при необходимости заменить исходный объект в будущем, но я хотел избежать этого сценария, если это вообще возможно. Поэтому я добавил дополнительный словарь, чтобы отслеживать, какие объекты гидратируются в любой момент времени, используя UUID объекта в качестве ключа и флуктуирующий счетчик, представляющий количество гидратаций без обезвоживания смещения. Моя цель с этим подходом состояла в том, чтобы DataController автоматически обезвоживал любой объект, когда его «счет удержания гидратации» достигает нуля, но это может легко привести к значительным утечкам памяти, поскольку в настоящее время он использует вызывающую программу для последующего вызова процедуры, которая уменьшает гидратацию сохранение счета объекта. Очевидно, есть много случаев, когда это просто неочевидно или, возможно, даже нелегко сделать, и если только один вызывающий объект не может сделать это должным образом, я сталкиваюсь с совершенно противоположным сценарием, который я пытался предотвратить в первую очередь. Иронично, да?
Во всяком случае, я думаю, что если я продолжу с этим подходом, это просто плохо кончится. Я испытываю желание вернуться к первоначальному плану, но из-за этого мне хочется съежиться, и я уверен, что есть более элегантное решение. Как я уже говорил, любой совет будет принят с благодарностью. Заранее спасибо.