Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Java [игнор отключен] [закрыт для гостей] / Совет по архитектуре компонента / 25 сообщений из 41, страница 1 из 2
12.03.2013, 15:23:45
    #38181475
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
Есть конфигурационный файл(формата properties). В нем перечислены через запятую элементы, которые необходимо загрузить из xml. Можно так же указать группу, не перечисляя все и загрузятся только те элементы, которые принадлежат к этой группе. В конфиге можно писать одновременно и группы и элементы из другой группы или которые не входят ни в какую группу. Этот конфиг заполняет пользователь. Данные из xml для каждого элемента грузятся по-разному в базу, но берутся из одного xml. Поэтому считаем что логика совершенно разная у каждого перечисленного элемента

Как лучше реализовать архитектуру данного компонента?
...
Рейтинг: 0 / 0
12.03.2013, 15:33:08
    #38181499
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
lukdiman,
Многовато задач для одного компонента.
Инкапсулировать \ декомпозировать на субкомпоненты.
И написать ограничения, т.е. что компонент и пользователь НЕ может и НЕ должен.
Например, xPath, который ты описал в первой части.
______________________________________________
"Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand.
AutoPOI.ru — ГИС-технологии для Oracle
...
Рейтинг: 0 / 0
12.03.2013, 15:46:45
    #38181528
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
Но тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь
...
Рейтинг: 0 / 0
12.03.2013, 15:51:33
    #38181538
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
lukdimanНо тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь
switch, обычно, легко заменяется полиморфизмом, кроме случаев вроде таблицы решений.
Покажите какой код получился, подскажем что поменять. Понять что нужно из такого сумбурного объяснения достаточно сложно.
...
Рейтинг: 0 / 0
12.03.2013, 16:04:34
    #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
12.03.2013, 16:07:11
    #38181571
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
Но полиморфизм породит тонну классов. Чем это будет лучше switch case?
...
Рейтинг: 0 / 0
12.03.2013, 16:13:16
    #38181579
Blazkowicz
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
lukdimanНо полиморфизм породит тонну классов.
Прям таки тонну? А switch для десятка стратегий с вложеной логикой будет нормально читаться?

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

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

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

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

в моём примере можно упихать все дерево в конструкторы enum, но я не знаю какова ваша конкретная ситуация, меняется ли глубина залегания узлов хml, и пр.. Пример так, чтобы показать как можно обходиться без кейсов. Делайте как вам нужно.
...
Рейтинг: 0 / 0
12.03.2013, 17:10:21
    #38181735
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
Вложенность не меняется. В принципе есть только элементы. Группы это надуманная абстракция, написав которую можно загрузить все элементы этой группы
...
Рейтинг: 0 / 0
12.03.2013, 17:37:19
    #38181775
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
- как описывается группа из N элементов?
- где парсер берёт данную информацию? Т.е. это будет второе дерево - xml в Prop....?
...
Рейтинг: 0 / 0
12.03.2013, 17:47:39
    #38181806
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
xml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу
...
Рейтинг: 0 / 0
12.03.2013, 17:49:33
    #38181811
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
lukdimanxml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу
приведи пример! сюда
...
Рейтинг: 0 / 0
12.03.2013, 18:03:01
    #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
12.03.2013, 18:12:42
    #38181848
Petro123
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
lukdimanВозможные группы таблиц: GROUP1(TABLE4, TABLE5)
Группы имеют смысл, когда их используют ПОВТОРНО где нибудь.
А так, пользователю нафиг надо их писать и описывать?
...
Рейтинг: 0 / 0
12.03.2013, 18:14:12
    #38181855
lukdiman
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Совет по архитектуре компонента
Зачем обсуждать как надо а как не надо? Это уже есть и от этого никуда не деться. Я спросил совета именно про текущую ситуацию, которую изменить я не могу в принципе
...
Рейтинг: 0 / 0
Форумы / Java [игнор отключен] [закрыт для гостей] / Совет по архитектуре компонента / 25 сообщений из 41, страница 1 из 2
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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