Своя объектная модель платформы типа 1С для Андроида #788942

Пожалуйста, накидайте советов, какая должна быть объектная модель платформы, аналогичной 1С, для ОС Андроид. Ну там объекты типа Справочник, Документ, Регистр... Или классы СправочникМенеджер, ЖурналДокументов, НаборЗаписейРегистра... Или пакет "Платформа" с абстрактными классами тип "Справочник", "ЭлементСправочника" и т.д.... Как оно всё должно быть в идеале? Пишу сейчас программу для учёта личных денег, но не хочется пользоваться 1С:Мобильным приложением по разным причинам. Уже написанный функционал вроде работает, но есть неудовлетворённость структурой классов, потому что получаются слишком большие классы (класс = файл), больше 1000 строк в файле. Как бы вы посоветовали организовать объектную модель, структуру классов, чтобы файлы были меньше тысячи строк? p.s. Язык программирования Java.

Забанили Гарикома, а он бы тут сразу свои соображения рассказал )

Он вызволен из бани стараниями модератора Лефмихалыча.

Только он обиделся и больше не придёт.

Вообще, зачем нужно идти по граблям 1С - документ и справочник - это одно и то же. Есть объект, у него есть какой-то набор полей, а какие-то поля могут быть таблицами или массивами - если это сделать, то будут вложенные таблицы из коробки, как это было в ACCESS, а не с бубнами, как это реализовано в 1С.

Документ проводится и делает движения по регистрам, а в своих реквизитах он содержит объекты учёта (справочники).

справочник, документ, это все называется таблица и есть основа баз данных, а вот от всего остального "от 1С" лучше отказаться сразу. Особенно, регистры, их не надо.

Регистры сворачивают итоги по измерениям. Регистры остатков получаются естественным образом из регистров оборотов, если просто просуммировать ресурсы по измерениям за весь период.

если не делать регистры, не придется ничего сворачивать;-) Это как из анекдота про машину: "столько всего успел сделать и помыл машину, и техосмотр прошел и страховку сделал, а без машины  - не смог бы".

Но если не делать регистры, то откуда отчёты будут брать данные?

Лучше ввести понятие кэш. При этом, кэш должен работать автоматически. К чему часто обращаются, то и агрегируется. И то только в том случае, если это даст существенное ускорение.

данные нужно брать... из данных наверное? единственно не получится программа "1С", ибо отчеты будут не "всегда за 1Секунду" получатся, а иногда за 5 секунд, или за 10 сек. Конечно, можно использовать промежуточные таблицы с "полупереваренными данными" (у нас две такие таблицы используются), но это никак не регистры. Регистры - это основное зло 1С.

Я вводил кэш и отказался от него из-за его тухлости. Представим, что БД маленькая и целиком хранится в оперативной памяти. Пусть кешированием занимается SQLitedatabase.

Если программа в Андроиде не отвечает за 5 секунд, то она считается зависшей. Я решил эту проблему асинхронным классом. Проблема в сабже по-прежнему актуальна.

На самом деле, регистр и есть кэш. Только не автоматический, а потому и бестолковый. Храним все по месяцам, а используем в 99% случаях актуальные итоги.

SQL тоже можно убрать.

Воу-воу! Полехче! SQL я не могу убрать

если отчет считается минуту, можно показывать мультики, или давать полезные советы;-)

ну мы убрали, у нас получилось.

Отчёт (Главное окно программы) должен показываться максимально быстро.

Это что за функционал на 1к строк там? От 1С в таком приложении ничего не нужно, документы/регистры тем более. Например класс "Операция" у которого есть тип (приход/расход - enum), категория (еда/кредиты/etc - класс "категория"), дата/сумма/etc. Каждый класс хранится в своей sql таблице. Соответственно из таблицы класса Операция можешь любой отчет построить. Типа расходы по категориям за месяц. Помоему все будет быстро и без кешей

Волшебник валит из 1С ))

Планириуется расширение функционала. Например, плановые операции и плановые регистры.

Я уже давно оттуда свалил. Вы просто не в теме.

Таблица + индексы + вьюшки отработают быстрее и универсальнее, чем регистры в 1С.

нужно забыть про концепции 1С - получится монстр но гигабайт, а это для андроида зло

Спасибо за совет. А можно реализовать платформу 1С для Андроида?

Плановые регистры это что? Наследуешься от операции, добавляешь функционал плановости, сохраняешь в новую таблицу, строишь по ней плановые отчеты, если я правильно понял

Кто будет качать на телефон прогу для учета финансов в Гб? Там места обычно не хватает всегда. Эта прога первая на удаление когда место кончится, какая бы "универсальная" внутри она не была.

Чем вам регистры не сдались ? Собственно, если мы хотим какие-то итоги получить, то нам или всегда считать всё или использовать кеширование, то есть итоги по определённым направлениям.

Зачем городить регистры в таком приложении? Это же не учетная система для бизнеса. С кешем и обычная HashMap справится

учет финансов - это круто, самое главное в такой программе - модуль скана и распознавания чеков. Если программа будет сама распознавать чеки и делать простейший отчет по закупкам, то она будет иметь успех.

в каком виде храните данные и насколько удобно с ними потом работать?

Или почитать учебник по базам данных и открыть для себя такой термин как индексы. :)))

вторая часть программы - это перевод сведений о платежах с карты с банкстерского на понятный язык. У банков настолько все замудрено, что большинству людей потребуется консультант, чтобы контролировать платежи.

храним внутри классов C++. Конечно С++ не так быстр как C, но пока устраивает. Используем одну из известных надстроек (набор библиотек), она не совсем устраивает, возможно со временем, уберем ее.

Индексы не спасают, когда нам нужны итоги по таблице. Индексы просто позволяют быстрее выбирать записи, если нам нужен итог по определённому типу записей.

Это точно не главное. Главное это остатки по счетам.

Главное - это вопрос планирования и анализа, чтобы можно было понять, на что и что было потрачено и нужно ли это было.

Это главное в прикладном решении, а я речь веду про платформу.

платформа нужна только в том случае если планируется разработать с десяток разных прикладных решений.

Хмм... Я выбрал секцию "убийцы 1С" с запасом. Хотелось бы понять в целом, как соотносятся друг с другом все эти сущности из сабжа.

В платформе самое важное - это интерфейс. Особенно, для мобильного приложения. Просто, при хранении объектов в памяти и небольшом количестве, проще не создавать лишних сущностей, так как это увеличит объём используемой памяти.

платформа не является интерфейсом, или я не прав? платформа предоставляет данные и всю функциональность для интерфейса (форм). Объём занимаемой памяти вообще не принимается во внимание. Представим, что у вас в распоряжении 3-4 Гб, которые занимает сам Андроид.

Если мы ведём расчёты в рублях, то под денежные величины в минимальной денежной единице хватает 5 байт (примерно 10 миллиардов рублей).

Если нам нужны итоги - мы создаем представление (view). А индексы позволяют сделать вьюшки быстрыми. Ну а если у нас большие таблицы с миллионами записей (к теме про Андроид это не очень относится, правда) - мы используем материализованные представления В MS SQL они называются индексированные представления.

Платформа - это движок, и самое в нём главное - это интерфейс, так как все остальные объекты можно и потом дописать.

А в Java нет partial class?

Надо пользоваться Xamarin

Так это аналог регистров и есть, только с произвольным, а не заранее заданным запросом. По сути говоря, нужен кеш, в котором хранятся последние результаты часто используемых запросов.

Java дарит возможность создать свои интерфейсы и разграничить их от своих платформ слоем объектов.

И, как бы, если мы отказываемся от SQL, то мы имеем гораздо больше счастья, чем горя.

Давайте все вместе забудем слово "кэш". Кэш не нужен! Проблем с памятью или скоростью нет!

Ну и, самое главное, что система должна обучаться и запоминать, какие запросы пользователь выполняет чаще, чтобы их результаты были готовы заранее.

Нет. Я фанат SQL. Других вариантов нет.

Да, только вьюшки работают 1. НАМНОГО быстрее регистров 1С 2. Для их реализации НЕ НАДО ПИСАТЬ кучу кода самому

Ну, можно это назвать по-другому - последние результаты вычисления. Например, текущий баланс можно хранить в каком-то месте и обновлять при вводе новых действий, а не рассчитывать каждый раз.

Тут я против. Система должна подкидывать сюрпризы пользователю

Первое счастье - придумывать формат хранения данных. :)))

Ну не всегда view работает очень быстро. Если у вас очень много записей, а тип выборки меняется, то перестроение View - это тоже некоторые задержки.

Свой код регистров уже написан и уже работает. Представим, что регистры уже есть. Что дальше?

Ну, как бы, можно придумать так, что будет работать быстро - тем более, что можно данные хранить вперемешку с метаданными и самими объектами.

Вот так всегда, самая не очень нужная вещь уже реализована, а что-то, что пользователь очень хочет - не будет никогда.

и раз , то эти 1000 строк чисто психологически давят? а робит все быстро и мгновенно получается забыть и не париться, пусть будет длинный но быстрый код :)

Можно. Но в таком случае, если можешь придумать быстрее, чем уже придумали в MS / Oracle / IBM - почему бы не написать им письмо? Вдруг они предложат нечто более привлекательное, чем написание своей платформы на Андроиде? :)))

Кстати, по поводу кеша - если у вас кеш в памяти и сами данные тоже в памяти, то иногда случаются ситуации, когда поиск данных в кеше выполняется намного дольше, чем само получение данных. Поэтому, подходить к реализации кеша нужно очень аккуратно, тогда он принесёт пользу, а не желание перезагрузить программу.

У них большие данные и в относительно медленных хранилищах - у нас мало данных в памяти. Конечно, ISAM от MySql будет тут как раз вовремя, но, можно просто у неё часть идей подсмотреть.

Если цель состоит просто покодить из любви к искусству - то да. А если хочется сделать, чтоб работало - то берешь уже нечто готовое (SQLite), и дописываешь то, чего в готовом виде нет.

Сейчас уже написано всё, что только можно, и по нескольку раз, просто, если это всё соединить, то получается неповоротливый монстр, так как одно требует другого и так далее. Иногда, лучше отбросить часть чего-то и получить меньший объём кода, чем пытаться использовать что-то стандартное с явно избыточным для задачи функционалом.

Нууу. Тогда надо открыть конфигуратор и идти дальше по списку. :)))

ну историю 1с не знаю, наверняка началось со справочников и документов, потом появились остальные "удобняшки". и если их повторять в убийце 1с под андроид по максимуму - то сама платформа уже перевалит порог адекватного занимаемого места. тем самым приложение apk будет много весить - если на это забить, то вперед, пока не упретесь в порог что дольше 5 сек думает :)

это и хотел сказать :) слизать с 1с

Я как то сомневаюсь, что SQLite будет причиной тормозов...

Да, психологически давят. Хочется иметь запас для роста. Если класс больше тысячи строк, я теряю над ним контроль.

юзать программу для учёта личных денег на опсосной платформе это как пытаться рассмешить всевышнего рассказывая ему о своих планах, не?

Дели на части - тогда будет понятно. P.S. к сожалению, в Java нельзя, чтобы каждая функция была в отдельном файле.

Мы с Богом в прекрасных отношениях. Я автоматизирую Его мир, он дарит мне счастье.

блажен кто верует, не ?)

А на какой платформе надо писать? :)))

потерпеть до wc не предлагать?

Java

Скл зло. Левые фреймворки зло.

Пожалуйста, накидайте советов, какая должна быть объектная модель платформы, аналогичной 1С... Пишу сейчас программу для учёта личных денег... Как бы вы посоветовали организовать объектную модель, структуру классов... Волшебник, ты хочешь полностью реализовать объектная модель? Или в данный момент реализовать учёта личных денег?

Я бы посоветовал концентрироваться на учете личных денег. Посмотреть какие объекты нужны. И брать за основу объекты 1С 7.7. И потом добавить нужные свойства и методы из 1С 8.х. Почему? Потому что в 1С 7.7 кол таблиц меньше. Так сказать необходимый минимум. >> Регистры сворачивают итоги по измерениям Тебе не нужно сворачивать. Держи сводную таблицу и заполняй/корректируй из регистра с помощью триггеров.

>есть неудовлетворённость структурой классов, потому что получаются слишком большие классы (класс = файл), больше 1000 строк в файле. Если проблема именно в этом, то от этого помогают паттерны. Совет - почитать классику и творчески применить.

"А можно реализовать платформу 1С для Андроида?" Ребята, лови наркомана!!!

Провёл рефакторинг своего проекта. Избавился от внутренних классов. Раскидал все классы по файлам, а родственные классы объединил в пакеты (packages). Структура теперь такая: пакет Платформа класс Справочник класс ЭлементСправочника класс Документ класс ЖурналДокументов класс Регистр класс ЗаписьРегистра От них наследуются конкретные справочники, документы и регистры, которые лежат в своих пакетах. Пакеты могут быть вложены друг в друга. Если какому-то объекту нужны другие объекты, он просто делает import и использует этот объект. Всем спасибо. Все свободны.

А как же набор записей?

Если еше в СУБД запихнуть все функции, хранимые процедуры т.е. оставить минимум для жабы...

ArrayList<RegistryRecord>

Ага, в SQLite запихнуть.

зачем SQLite? лучше в дбф-ку :-(

MySQL на сервере через POST запросы

У меня другая концепция. Всё должно быть локально в телефоне/планшете.

Станислав, а ты куда ушел из 1с? и как у тебя с тренировками, результатами дела? Где это можно прочитать?