powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Совет по архитектуре компонента
41 сообщений из 41, показаны все 2 страниц
Совет по архитектуре компонента
    #38181475
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть конфигурационный файл(формата properties). В нем перечислены через запятую элементы, которые необходимо загрузить из xml. Можно так же указать группу, не перечисляя все и загрузятся только те элементы, которые принадлежат к этой группе. В конфиге можно писать одновременно и группы и элементы из другой группы или которые не входят ни в какую группу. Этот конфиг заполняет пользователь. Данные из xml для каждого элемента грузятся по-разному в базу, но берутся из одного xml. Поэтому считаем что логика совершенно разная у каждого перечисленного элемента

Как лучше реализовать архитектуру данного компонента?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181499
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,
Многовато задач для одного компонента.
Инкапсулировать \ декомпозировать на субкомпоненты.
И написать ограничения, т.е. что компонент и пользователь НЕ может и НЕ должен.
Например, xPath, который ты описал в первой части.
______________________________________________
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
AutoPOI.ru — ГИС-технологии для Oracle
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181528
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Но тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181538
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanНо тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь
switch, обычно, легко заменяется полиморфизмом, кроме случаев вроде таблицы решений.
Покажите какой код получился, подскажем что поменять. Понять что нужно из такого сумбурного объяснения достаточно сложно.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181568
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделайте enum со стратегией например
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
import java.util.ArrayList;
import java.util.List;

public enum XmlCase {
    ROOT(new RootLoader()),
    TOVARY(ROOT, new TovarLoader()),
    KLIENTY(ROOT, new ClientLoader());

    private Loader  loader;
    private XmlCase parent;
    private final List<XmlCase> children = new ArrayList<XmlCase>();

    XmlCase() {
        parent = null;
    }

    /* main method */
    void load(Config config, Object xml) {
        if (config.isSelected(this)) {
            loader.load(xml);
            for (XmlCase caze : children) {
                caze.load(config, xml);
            }
        }
    }

    XmlCase(XmlCase root, Loader loader) {
        this.parent = root;
        this.loader = loader;
        parent.children.add(this);

    }

    XmlCase(Loader loader) {
        this.loader = loader;
    }
}

/* your implementation */
interface Config {
    boolean isSelected(XmlCase caze);
}

/* your implementation */
interface Loader {
    void load(Object xml);
}

/* your implementation */
class RootLoader implements Loader {

    @Override
    public void load(Object xml) {

    }
}

/* your implementation */
class TovarLoader implements Loader {

    @Override
    public void load(Object xml) {

    }
}


/* your implementation */
class ClientLoader implements Loader {

    @Override
    public void load(Object xml) {

    }
}
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181571
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Но полиморфизм породит тонну классов. Чем это будет лучше switch case?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181579
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanНо полиморфизм породит тонну классов.
Прям таки тонну? А switch для десятка стратегий с вложеной логикой будет нормально читаться?

lukdimanЧем это будет лучше switch case?
Тем же чем OOP лучше процедурного подхода. Уменьшить размеры методов. Кода будет меньше. Он будет лучше читаться. Если нужно создать иерархию, в которой больше одного родителя, то на switch..case это будет выглядеть ещё запутаннее.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181585
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не тонну, но 20-30 точно. Но выбирать какой класс использовать все равно придется через switch
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181593
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,

у меня в enum нет свитчя ^^
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181595
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanНе тонну, но 20-30 точно. Но выбирать какой класс использовать все равно придется через switch
Не обязательно. Можно через Map или Class.forName().
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181602
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanНо тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь
вот с этого и начните.
Есть ЯП - SQL
Есть ЯП - xPath
Приведите пример ЯП по которому пользователь будет выбирать Группы\Элементы
И уточните, атрибут в терминологии XML для вас это что?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181604
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Лагман, Ваш enum не скомпилируется. Так нельзя писать
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181606
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,

вобще-то можно, но лучше конечно разнести по отдельным файлам
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181613
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Blazkowicz,

можно загнать все в jaxb, если конечно группы и элементы это путь а не условие на значение атрибута.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181614
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanЛагман, Ваш enum не скомпилируется. Так нельзя писать
То что конкретный пример не компилируется ещё не значит что весь подход не верен. Так можно писать.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181617
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Лагманвобще-то можно, но лучше конечно разнести по отдельным файлам
Через enum удобно как раз dispatch сделать на какие-то корневые классы. А там уже логику отдельную держать в каждом класса или иерархии.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181695
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А если группа, то получается надо еще внутри групповых лоадеров создавать лист чилдовых?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181714
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,

в моём примере можно упихать все дерево в конструкторы enum, но я не знаю какова ваша конкретная ситуация, меняется ли глубина залегания узлов хml, и пр.. Пример так, чтобы показать как можно обходиться без кейсов. Делайте как вам нужно.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181735
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Вложенность не меняется. В принципе есть только элементы. Группы это надуманная абстракция, написав которую можно загрузить все элементы этой группы
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181775
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
- как описывается группа из N элементов?
- где парсер берёт данную информацию? Т.е. это будет второе дерево - xml в Prop....?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181806
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
xml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181811
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanxml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу
приведи пример! сюда
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181836
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Возможные таблицы(узлы xml файла): TABLE1, TABLE2, TABLE3, TABLE4, TABLE5, TABLE6
Возможные группы таблиц: GROUP1(TABLE4, TABLE5)

loader.properties

table=TABLE1,TABLE2,TABLE3,GROUP1

Пример xml файла:
Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
<tables>
    <TABLE1>
    <!--Данные 1-->
    </TABLE1>
    <TABLE2>
    <!--Данные 2-->
    </TABLE2>
    ....
    <TABLE_N>
    <!--данные N-->
    </TABLE_N>
</tables>
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181848
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanВозможные группы таблиц: GROUP1(TABLE4, TABLE5)
Группы имеют смысл, когда их используют ПОВТОРНО где нибудь.
А так, пользователю нафиг надо их писать и описывать?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181855
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Зачем обсуждать как надо а как не надо? Это уже есть и от этого никуда не деться. Я спросил совета именно про текущую ситуацию, которую изменить я не могу в принципе
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181893
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanЗачем обсуждать как надо а как не надо? Это уже есть и от этого никуда не деться. Я спросил совета именно про текущую ситуацию, которую изменить я не могу в принципе
текущая ситуация - это:
- в XML любым парсером, любой элемент - это Node.
Поэтому, если на входе поиска Ноды - строка, То непонятно почему много вариантов:

Код: java
1.
Node = НайтиЭлемент(СтрокаИмя, XML)
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38181996
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
содержимое разное и обрабатывается по-разному
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182145
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,

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

если хочешь то можешь называть класс обработчик также как и его xpatch. Например ProcessTablesTable1.
зная логику именования классов, ты сможешь всегда получить название класса из xpath, правильно вызвать класслоадер и соответственно обойтись без swicth и т.п.
сли обработчик найдет свой корень то сделает работу, если не найдет, то завершится. вроде быстро должно проскакивать.

Если в XML окажется корень для которого еще не написан класс обработчик, то будет эксепшн. класс нот фаунд. он тоже встраивается в логику.

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


так нельзя сделать?

PS я сам нуб. просто интересуюсь.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182148
Кореец
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
>сли обработчик найдет свой корень то сделает работу, если не найдет, то завершится. вроде быстро должно проскакивать.

кстати этого не произойдет. первичный загрузчик вызовет только те обработчики для которых найдется их XPATH
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182163
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
switch, обычно, легко заменяется полиморфизмом, кроме случаев вроде таблицы решений.
А полиморфизм легко заменяется свитчем, при это код становится намного понятнее.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182181
Лагман
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Йуный джавистЪ,

только на собеседованиях этого не говорите
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182185
Йуный джавистЪ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
только на собеседованиях этого не говорите
Наоборот, обязательно говорю. Если такое высказывание шокируют нанимателя, то мне с ним не по пути.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182275
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Йуный джавистЪтолько на собеседованиях этого не говорите
Наоборот, обязательно говорю. Если такое высказывание шокируют нанимателя, то мне с ним не по пути.

Не всегда собеседуют те, с кем будешь в дальнейшем работать.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182513
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я решил остановиться на таком варианте. В enum описываю все таблицы и все группы. Для каждой таблицы в конструктор передаю объект поведения. У групповых описываю базовое поведение для групп и передаю таблицы, которые входят в эти группы. У всех единый интерфейс, но у конкретных таблиц будет напрямую вызов прогрузки данных, а групповые будут пробегать по своим таблицам и вызывать у них тот же метод, объявленный в едином интерфейсе. Мне кажется оптимальное решение(хоть и много классов) и позволяет избавиться от switch case.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182595
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanсодержимое разное и обрабатывается по-разному
и это вся твоя конкретика?
Или у тебя уникальный XML.
У всех Node - разное содержимое)
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182599
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdiman,
пока ты не расшифруешь РАЗНИЦУ в таблицах АКА свитчах - будет пустой трёп.
Забей в XML скрипты DDL\DDL и свитчи не понадобятся))
ЗЫ.
Разное поведение, это бизнес-логика. Засунуть её в XML не удастся (дкларативно).
Удачи!
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182603
lukdiman
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Потому что я считаю для решения данной задачи конкретика не должна волновать. Я думаю над созданием более высокого слоя чем конкретика каждой ноды. А что там и как будет обрабатываться на данном этапе не должно интересовать и не влияет ни на что
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182613
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Корееци соответственно обойтись без swicth и т.п.
+1
Можно прямо в ноде XML прописать ИмяБЛфункции по обработке.
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182618
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
lukdimanПотому что я считаю для решения данной задачи конкретика не должна волновать. Я думаю над созданием более высокого слоя чем конкретика каждой ноды. А что там и как будет обрабатываться на данном этапе не должно интересовать и не влияет ни на что
конкретика - это свитч . Я тебе показал без него.
swicth - по имени ноды или по какому признаку тебе нужны?
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182654
am_sasa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Petro123Можно прямо в ноде XML прописать ИмяБЛфункции по обработке. да! точно! получится Spring IoC
...
Рейтинг: 0 / 0
Совет по архитектуре компонента
    #38182664
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
am_sasa,
в 1С делают круче. Там в файле экспорта проводок идут данные прямо с кодом вместе)
...
Рейтинг: 0 / 0
41 сообщений из 41, показаны все 2 страниц
Форумы / Java [игнор отключен] [закрыт для гостей] / Совет по архитектуре компонента
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]