Имя: Пароль:
IT
 
Своя объектная модель платформы типа 1С для Андроида
Ø (Волшебник 15.01.2017 00:15)
, ,
0 Волшебник
 
модератор
13.01.17
21:49
Пожалуйста, накидайте советов, какая должна быть объектная модель платформы, аналогичной 1С, для ОС Андроид.

Ну там объекты типа Справочник, Документ, Регистр... Или классы СправочникМенеджер, ЖурналДокументов, НаборЗаписейРегистра... Или пакет "Платформа" с абстрактными классами тип "Справочник", "ЭлементСправочника" и т.д.... Как оно всё должно быть в идеале?

Пишу сейчас программу для учёта личных денег, но не хочется пользоваться 1С:Мобильным приложением по разным причинам. Уже написанный функционал вроде работает, но есть неудовлетворённость структурой классов, потому что получаются слишком большие классы (класс = файл), больше 1000 строк в файле.

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

p.s. Язык программирования Java.
1 Cyberhawk
 
13.01.17
21:58
Забанили Гарикома, а он бы тут сразу свои соображения рассказал )
2 Волшебник
 
модератор
13.01.17
22:03
(1) Он вызволен из бани стараниями модератора Лефмихалыча.
3 Torquader
 
13.01.17
22:07
Только он обиделся и больше не придёт.
4 Torquader
 
13.01.17
22:09
Вообще, зачем нужно идти по граблям 1С - документ и справочник - это одно и то же.
Есть объект, у него есть какой-то набор полей, а какие-то поля могут быть таблицами или массивами - если это сделать, то будут вложенные таблицы из коробки, как это было в ACCESS, а не с бубнами, как это реализовано в 1С.
5 Волшебник
 
модератор
13.01.17
22:10
(4) Документ проводится и делает движения по регистрам, а в своих реквизитах он содержит объекты учёта (справочники).
6 Маус
 
13.01.17
22:11
справочник, документ, это все называется таблица и есть основа баз данных, а вот от всего остального "от 1С" лучше отказаться сразу. Особенно, регистры, их не надо.
7 Волшебник
 
модератор
13.01.17
22:14
(6) Регистры сворачивают итоги по измерениям. Регистры остатков получаются естественным образом из регистров оборотов, если просто просуммировать ресурсы по измерениям за весь период.
8 Маус
 
13.01.17
22:18
(7) если не делать регистры, не придется ничего сворачивать;-) Это как из анекдота про машину: "столько всего успел сделать и помыл машину, и техосмотр прошел и страховку сделал, а без машины  - не смог бы".
9 Волшебник
 
модератор
13.01.17
22:18
(8) Но если не делать регистры, то откуда отчёты будут брать данные?
10 mkalimulin
 
13.01.17
22:22
(7) Лучше ввести понятие кэш. При этом, кэш должен работать автоматически. К чему часто обращаются, то и агрегируется. И то только в том случае, если это даст существенное ускорение.
11 Маус
 
13.01.17
22:22
данные нужно брать... из данных наверное?
единственно не получится программа "1С", ибо отчеты будут не "всегда за 1Секунду" получатся, а иногда за 5 секунд, или за 10 сек. Конечно, можно использовать промежуточные таблицы с "полупереваренными данными" (у нас две такие таблицы используются), но это никак не регистры. Регистры - это основное зло 1С.
12 Волшебник
 
модератор
13.01.17
22:23
(10) Я вводил кэш и отказался от него из-за его тухлости. Представим, что БД маленькая и целиком хранится в оперативной памяти. Пусть кешированием занимается SQLitedatabase.
13 Волшебник
 
модератор
13.01.17
22:25
(11) Если программа в Андроиде не отвечает за 5 секунд, то она считается зависшей. Я решил эту проблему асинхронным классом.

Проблема в сабже по-прежнему актуальна.
14 mkalimulin
 
13.01.17
22:25
(12) На самом деле, регистр и есть кэш. Только не автоматический, а потому и бестолковый. Храним все по месяцам, а используем в 99% случаях актуальные итоги.
15 Маус
 
13.01.17
22:25
SQL тоже можно убрать.
16 Волшебник
 
модератор
13.01.17
22:26
(15) Воу-воу! Полехче! SQL я не могу убрать
17 Маус
 
13.01.17
22:26
если отчет считается минуту, можно показывать мультики, или давать полезные советы;-)
18 Маус
 
13.01.17
22:27
(16) ну мы убрали, у нас получилось.
19 Волшебник
 
модератор
13.01.17
22:27
(17) Отчёт (Главное окно программы) должен показываться максимально быстро.
20 Encode
 
13.01.17
22:30
(0) Это что за функционал на 1к строк там? От 1С в таком приложении ничего не нужно, документы/регистры тем более. Например класс "Операция" у которого есть тип (приход/расход - enum), категория (еда/кредиты/etc - класс "категория"), дата/сумма/etc. Каждый класс хранится в своей sql таблице. Соответственно из таблицы класса Операция можешь любой отчет построить. Типа расходы по категориям за месяц. Помоему все будет быстро и без кешей
21 neomarat
 
13.01.17
22:30
Волшебник валит из 1С ))
22 Волшебник
 
модератор
13.01.17
22:31
(20) Планириуется расширение функционала. Например, плановые операции и плановые регистры.
23 Волшебник
 
модератор
13.01.17
22:31
(21) Я уже давно оттуда свалил. Вы просто не в теме.
24 s_ustinov
 
13.01.17
22:34
(9) Таблица + индексы + вьюшки отработают быстрее и универсальнее, чем регистры в 1С.
25 neomarat
 
13.01.17
22:34
нужно забыть про концепции 1С - получится монстр но гигабайт, а это для андроида зло
26 Волшебник
 
модератор
13.01.17
22:35
(25) Спасибо за совет. А можно реализовать платформу 1С для Андроида?
27 Encode
 
13.01.17
22:37
(22) Плановые регистры это что? Наследуешься от операции, добавляешь функционал плановости, сохраняешь в новую таблицу, строишь по ней плановые отчеты, если я правильно понял
28 neomarat
 
13.01.17
22:39
Кто будет качать на телефон прогу для учета финансов в Гб? Там места обычно не хватает всегда. Эта прога первая на удаление когда место кончится, какая бы "универсальная" внутри она не была.
29 Torquader
 
13.01.17
22:40
Чем вам регистры не сдались ?
Собственно, если мы хотим какие-то итоги получить, то нам или всегда считать всё или использовать кеширование, то есть итоги по определённым направлениям.
30 Encode
 
13.01.17
22:44
(29) Зачем городить регистры в таком приложении? Это же не учетная система для бизнеса. С кешем и обычная HashMap справится
31 Маус
 
13.01.17
22:44
учет финансов - это круто, самое главное в такой программе - модуль скана и распознавания чеков. Если программа будет сама распознавать чеки и делать простейший отчет по закупкам, то она будет иметь успех.
32 бегинер
 
13.01.17
22:47
(18) в каком виде храните данные и насколько удобно с ними потом работать?
33 s_ustinov
 
13.01.17
22:49
(29) Или почитать учебник по базам данных и открыть для себя такой термин как индексы. :)))
34 Маус
 
13.01.17
22:49
вторая часть программы - это перевод сведений о платежах с карты с банкстерского на понятный язык. У банков настолько все замудрено, что большинству людей потребуется консультант, чтобы контролировать платежи.
35 Маус
 
13.01.17
22:53
(32) храним внутри классов C++. Конечно С++ не так быстр как C, но пока устраивает. Используем одну из известных надстроек (набор библиотек), она не совсем устраивает, возможно со временем, уберем ее.
36 Torquader
 
13.01.17
22:56
(33) Индексы не спасают, когда нам нужны итоги по таблице.
Индексы просто позволяют быстрее выбирать записи, если нам нужен итог по определённому типу записей.
37 Волшебник
 
13.01.17
22:56
(31) Это точно не главное.
Главное это остатки по счетам.
38 Torquader
 
13.01.17
22:57
(37) Главное - это вопрос планирования и анализа, чтобы можно было понять, на что и что было потрачено и нужно ли это было.
39 Волшебник
 
13.01.17
22:58
(38) Это главное в прикладном решении, а я речь веду про платформу.
40 Маус
 
13.01.17
23:01
(39) платформа нужна только в том случае если планируется разработать с десяток разных прикладных решений.
41 Волшебник
 
13.01.17
23:03
(40) Хмм... Я выбрал секцию "убийцы 1С" с запасом. Хотелось бы понять в целом, как соотносятся друг с другом все эти сущности из сабжа.
42 Torquader
 
13.01.17
23:10
(39) В платформе самое важное - это интерфейс.
Особенно, для мобильного приложения.
Просто, при хранении объектов в памяти и небольшом количестве, проще не создавать лишних сущностей, так как это увеличит объём используемой памяти.
43 Волшебник
 
13.01.17
23:12
(42) платформа не является интерфейсом, или я не прав? платформа предоставляет данные и всю функциональность для интерфейса (форм).

Объём занимаемой памяти вообще не принимается во внимание. Представим, что у вас в распоряжении 3-4 Гб, которые занимает сам Андроид.
44 Torquader
 
13.01.17
23:15
Если мы ведём расчёты в рублях, то под денежные величины в минимальной денежной единице хватает 5 байт (примерно 10 миллиардов рублей).
45 s_ustinov
 
13.01.17
23:15
(36) Если нам нужны итоги - мы создаем представление (view). А индексы позволяют сделать вьюшки быстрыми.
Ну а если у нас большие таблицы с миллионами записей (к теме про Андроид это не очень относится, правда) - мы используем материализованные представления https://ru.wikipedia.org/wiki/Материализованное_представление
В MS SQL они называются индексированные представления.
46 Torquader
 
13.01.17
23:16
(43) Платформа - это движок, и самое в нём главное - это интерфейс, так как все остальные объекты можно и потом дописать.
47 Serginio1
 
13.01.17
23:16
А в Java нет partial class?
48 Serginio1
 
13.01.17
23:17
Надо пользоваться Xamarin
49 Torquader
 
13.01.17
23:17
(45) Так это аналог регистров и есть, только с произвольным, а не заранее заданным запросом.
По сути говоря, нужен кеш, в котором хранятся последние результаты часто используемых запросов.
50 Волшебник
 
13.01.17
23:18
(46) Java дарит возможность создать свои интерфейсы и разграничить их от своих платформ слоем объектов.
51 Torquader
 
13.01.17
23:18
И, как бы, если мы отказываемся от SQL, то мы имеем гораздо больше счастья, чем горя.
52 Волшебник
 
13.01.17
23:19
(49) Давайте все вместе забудем слово "кэш". Кэш не нужен! Проблем с памятью или скоростью нет!
53 Torquader
 
13.01.17
23:19
Ну и, самое главное, что система должна обучаться и запоминать, какие запросы пользователь выполняет чаще, чтобы их результаты были готовы заранее.
54 Волшебник
 
13.01.17
23:20
(51) Нет. Я фанат SQL. Других вариантов нет.
55 s_ustinov
 
13.01.17
23:20
(49) Да, только вьюшки работают
1. НАМНОГО быстрее регистров 1С
2. Для их реализации НЕ НАДО ПИСАТЬ кучу кода самому
56 Torquader
 
13.01.17
23:20
(52) Ну, можно это назвать по-другому - последние результаты вычисления.
Например, текущий баланс можно хранить в каком-то месте и обновлять при вводе новых действий, а не рассчитывать каждый раз.
57 Волшебник
 
13.01.17
23:20
(53) Тут я против. Система должна подкидывать сюрпризы пользователю
58 s_ustinov
 
13.01.17
23:21
(51) Первое счастье - придумывать формат хранения данных. :)))
59 Torquader
 
13.01.17
23:21
(55) Ну не всегда view работает очень быстро. Если у вас очень много записей, а тип выборки меняется, то перестроение View - это тоже некоторые задержки.
60 Волшебник
 
13.01.17
23:21
(55) Свой код регистров уже написан и уже работает. Представим, что регистры уже есть. Что дальше?
61 Torquader
 
13.01.17
23:22
(58) Ну, как бы, можно придумать так, что будет работать быстро - тем более, что можно данные хранить вперемешку с метаданными и самими объектами.
62 Torquader
 
13.01.17
23:22
(60) Вот так всегда, самая не очень нужная вещь уже реализована, а что-то, что пользователь очень хочет - не будет никогда.
63 бегинер
 
13.01.17
23:23
(0) и раз (52), то эти 1000 строк чисто психологически давят?
а робит все быстро и мгновенно получается
забыть и не париться, пусть будет длинный но быстрый код :)
64 s_ustinov
 
13.01.17
23:25
(61) Можно. Но в таком случае, если можешь придумать быстрее, чем уже придумали в MS / Oracle / IBM - почему бы не написать им письмо? Вдруг они предложат нечто более привлекательное, чем написание своей платформы на Андроиде? :)))
65 Torquader
 
13.01.17
23:25
Кстати, по поводу кеша - если у вас кеш в памяти и сами данные тоже в памяти, то иногда случаются ситуации, когда поиск данных в кеше выполняется намного дольше, чем само получение данных.
Поэтому, подходить к реализации кеша нужно очень аккуратно, тогда он принесёт пользу, а не желание перезагрузить программу.
66 Torquader
 
13.01.17
23:26
(64) У них большие данные и в относительно медленных хранилищах - у нас мало данных в памяти. Конечно, ISAM от MySql будет тут как раз вовремя, но, можно просто у неё часть идей подсмотреть.
67 s_ustinov
 
13.01.17
23:29
(66) Если цель состоит просто покодить из любви к искусству - то да. А если хочется сделать, чтоб работало - то берешь уже нечто готовое (SQLite), и дописываешь то, чего в готовом виде нет.
68 Torquader
 
13.01.17
23:30
(67) Сейчас уже написано всё, что только можно, и по нескольку раз, просто, если это всё соединить, то получается неповоротливый монстр, так как одно требует другого и так далее. Иногда, лучше отбросить часть чего-то и получить меньший объём кода, чем пытаться использовать что-то стандартное с явно избыточным для задачи функционалом.
69 s_ustinov
 
13.01.17
23:31
(60) Нууу. Тогда надо открыть конфигуратор и идти дальше по списку. :)))
70 бегинер
 
13.01.17
23:32
ну историю 1с не знаю, наверняка началось со справочников и документов, потом появились остальные "удобняшки". и если их повторять в убийце 1с под андроид по максимуму - то сама платформа уже перевалит порог адекватного занимаемого места.
тем самым приложение apk будет много весить - если на это забить, то вперед, пока не упретесь в порог что дольше 5 сек думает :)
71 бегинер
 
13.01.17
23:32
(69) это и хотел сказать :)
слизать с 1с
72 s_ustinov
 
13.01.17
23:32
(68) Я как то сомневаюсь, что SQLite будет причиной тормозов...
73 Волшебник
 
13.01.17
23:32
(63) Да, психологически давят.
Хочется иметь запас для роста.
Если класс больше тысячи строк, я теряю над ним контроль.
74 ifso
 
13.01.17
23:36
юзать программу для учёта личных денег на опсосной платформе это как пытаться рассмешить всевышнего рассказывая ему о своих планах, не?
75 Torquader
 
13.01.17
23:37
(73) Дели на части - тогда будет понятно.
P.S. к сожалению, в Java нельзя, чтобы каждая функция была в отдельном файле.
76 Волшебник
 
13.01.17
23:39
(74) Мы с Богом в прекрасных отношениях. Я автоматизирую Его мир, он дарит мне счастье.
77 ifso
 
13.01.17
23:42
(76) блажен кто верует, не ?)
78 s_ustinov
 
13.01.17
23:43
(74) А на какой платформе надо писать? :)))
79 ifso
 
13.01.17
23:56
(78) потерпеть до wc не предлагать?
80 Волшебник
 
13.01.17
23:57
(78) Java
81 Злопчинский
 
14.01.17
02:31
82 Agent ООЗ
 
14.01.17
05:05
Скл зло. Левые фреймворки зло.
83 _Atilla
 
14.01.17
12:54
(0) Пожалуйста, накидайте советов, какая должна быть объектная модель платформы, аналогичной 1С...

Пишу сейчас программу для учёта личных денег...

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

Волшебник, ты хочешь полностью реализовать объектная модель?
Или в данный момент реализовать учёта личных денег?
84 _Atilla
 
14.01.17
13:09
(83) Я бы посоветовал концентрироваться на учете личных денег.
Посмотреть какие объекты нужны. И брать за основу объекты 1С 7.7. И потом добавить нужные свойства и методы из 1С 8.х.

Почему? Потому что в 1С 7.7 кол таблиц меньше. Так сказать необходимый минимум.

>> Регистры сворачивают итоги по измерениям
Тебе не нужно сворачивать. Держи сводную таблицу и заполняй/корректируй из регистра с помощью триггеров.
85 mistеr
 
14.01.17
14:46
(0) >есть неудовлетворённость структурой классов, потому что получаются слишком большие классы (класс = файл), больше 1000 строк в файле.

Если проблема именно в этом, то от этого помогают паттерны. Совет - почитать классику и творчески применить.
86 lock19
 
14.01.17
15:39
87 dumb851
 
14.01.17
17:54
(26) "А можно реализовать платформу 1С для Андроида?"
Ребята, лови наркомана!!!
88 Волшебник
 
модератор
14.01.17
18:58
Провёл рефакторинг своего проекта. Избавился от внутренних классов. Раскидал все классы по файлам, а родственные классы объединил в пакеты (packages).

Структура теперь такая:

пакет Платформа
класс Справочник
класс ЭлементСправочника
класс Документ
класс ЖурналДокументов
класс Регистр
класс ЗаписьРегистра

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

Если какому-то объекту нужны другие объекты, он просто делает import и использует этот объект.

Всем спасибо. Все свободны.
89 mistеr
 
14.01.17
19:57
(88) А как же набор записей?
90 _Atilla
 
14.01.17
20:18
(83) Если еше в СУБД запихнуть все функции, хранимые процедуры т.е. оставить минимум для жабы...
91 Волшебник
 
модератор
14.01.17
20:33
(89) ArrayList<RegistryRecord>
92 mistеr
 
14.01.17
20:34
(90) Ага, в SQLite запихнуть.
93 _Atilla
 
14.01.17
21:26
(92) зачем SQLite?

лучше в дбф-ку :-(
94 _Atilla
 
14.01.17
21:34
MySQL на сервере через POST запросы
95 Волшебник
 
модератор
14.01.17
21:54
(94) У меня другая концепция. Всё должно быть локально в телефоне/планшете.
96 Tarzan_Pasha
 
14.01.17
23:23
(95)Станислав, а ты куда ушел из 1с? и как у тебя с тренировками, результатами дела? Где это можно прочитать?
Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Эдвард Йодан