|
|
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Есть конфигурационный файл(формата properties). В нем перечислены через запятую элементы, которые необходимо загрузить из xml. Можно так же указать группу, не перечисляя все и загрузятся только те элементы, которые принадлежат к этой группе. В конфиге можно писать одновременно и группы и элементы из другой группы или которые не входят ни в какую группу. Этот конфиг заполняет пользователь. Данные из xml для каждого элемента грузятся по-разному в базу, но берутся из одного xml. Поэтому считаем что логика совершенно разная у каждого перечисленного элемента Как лучше реализовать архитектуру данного компонента? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 15:23:45 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, Многовато задач для одного компонента. Инкапсулировать \ декомпозировать на субкомпоненты. И написать ограничения, т.е. что компонент и пользователь НЕ может и НЕ должен. Например, xPath, который ты описал в первой части. ______________________________________________ "Сложнее всего в мире достигнуть простоты — это крайняя граница опыта и последнее усилие гения". © George Sand. AutoPOI.ru — ГИС-технологии для Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 15:33:08 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Но тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 15:46:45 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanНо тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь switch, обычно, легко заменяется полиморфизмом, кроме случаев вроде таблицы решений. Покажите какой код получился, подскажем что поменять. Понять что нужно из такого сумбурного объяснения достаточно сложно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 15:51:33 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Сделайте 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:04:34 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Но полиморфизм породит тонну классов. Чем это будет лучше switch case? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:07:11 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanНо полиморфизм породит тонну классов. Прям таки тонну? А switch для десятка стратегий с вложеной логикой будет нормально читаться? lukdimanЧем это будет лучше switch case? Тем же чем OOP лучше процедурного подхода. Уменьшить размеры методов. Кода будет меньше. Он будет лучше читаться. Если нужно создать иерархию, в которой больше одного родителя, то на switch..case это будет выглядеть ещё запутаннее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:13:16 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Не тонну, но 20-30 точно. Но выбирать какой класс использовать все равно придется через switch ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:15:03 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, у меня в enum нет свитчя ^^ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:18:06 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanНе тонну, но 20-30 точно. Но выбирать какой класс использовать все равно придется через switch Не обязательно. Можно через Map или Class.forName(). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:18:53 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanНо тем не менее такая задача есть и ее надо делать :) И меньше требований к компоненту не будет. У меня получается слишком много switch case потому что очень много разных элементов, которые может написать пользователь вот с этого и начните. Есть ЯП - SQL Есть ЯП - xPath Приведите пример ЯП по которому пользователь будет выбирать Группы\Элементы И уточните, атрибут в терминологии XML для вас это что? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:22:43 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Лагман, Ваш enum не скомпилируется. Так нельзя писать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:22:54 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, вобще-то можно, но лучше конечно разнести по отдельным файлам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:23:56 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Blazkowicz, можно загнать все в jaxb, если конечно группы и элементы это путь а не условие на значение атрибута. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:25:07 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanЛагман, Ваш enum не скомпилируется. Так нельзя писать То что конкретный пример не компилируется ещё не значит что весь подход не верен. Так можно писать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:25:25 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Лагманвобще-то можно, но лучше конечно разнести по отдельным файлам Через enum удобно как раз dispatch сделать на какие-то корневые классы. А там уже логику отдельную держать в каждом класса или иерархии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:26:30 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
А если группа, то получается надо еще внутри групповых лоадеров создавать лист чилдовых? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 16:54:27 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, в моём примере можно упихать все дерево в конструкторы enum, но я не знаю какова ваша конкретная ситуация, меняется ли глубина залегания узлов хml, и пр.. Пример так, чтобы показать как можно обходиться без кейсов. Делайте как вам нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 17:01:43 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Вложенность не меняется. В принципе есть только элементы. Группы это надуманная абстракция, написав которую можно загрузить все элементы этой группы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 17:10:21 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
- как описывается группа из N элементов? - где парсер берёт данную информацию? Т.е. это будет второе дерево - xml в Prop....? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 17:37:19 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
xml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 17:47:39 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanxml идет отдельным файлом. в пропертях описывается только список узлов, которые надо загрузить или группа. группа состоит из нескольких узлов, которые надо прогрузить. в основе всего все равно лежат эти узлы. просто придумали группы чтобы не перечислять через запятую их если надо прогрузить все сразу приведи пример! сюда ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 17:49:33 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Возможные таблицы(узлы 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 18:03:01 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanВозможные группы таблиц: GROUP1(TABLE4, TABLE5) Группы имеют смысл, когда их используют ПОВТОРНО где нибудь. А так, пользователю нафиг надо их писать и описывать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 18:12:42 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Зачем обсуждать как надо а как не надо? Это уже есть и от этого никуда не деться. Я спросил совета именно про текущую ситуацию, которую изменить я не могу в принципе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 18:14:12 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanЗачем обсуждать как надо а как не надо? Это уже есть и от этого никуда не деться. Я спросил совета именно про текущую ситуацию, которую изменить я не могу в принципе текущая ситуация - это: - в XML любым парсером, любой элемент - это Node. Поэтому, если на входе поиска Ноды - строка, То непонятно почему много вариантов: Код: java 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 18:40:45 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
содержимое разное и обрабатывается по-разному ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 20:04:43 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, а нельзя просто для каждого из корневых элементов определить свой класс обработчик? путь будет один базовый класс с методами по работе с xml, и наследуемые от него с самой логикой обработки. в обработчике держать путь к своему корню xml и логику. если хочешь то можешь называть класс обработчик также как и его xpatch. Например ProcessTablesTable1. зная логику именования классов, ты сможешь всегда получить название класса из xpath, правильно вызвать класслоадер и соответственно обойтись без swicth и т.п. сли обработчик найдет свой корень то сделает работу, если не найдет, то завершится. вроде быстро должно проскакивать. Если в XML окажется корень для которого еще не написан класс обработчик, то будет эксепшн. класс нот фаунд. он тоже встраивается в логику. Заодно вызов обработчиков можешь делать в отдельный поток - вот тебе и паралельность для каждого варианта данных. так нельзя сделать? PS я сам нуб. просто интересуюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 22:41:21 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
>сли обработчик найдет свой корень то сделает работу, если не найдет, то завершится. вроде быстро должно проскакивать. кстати этого не произойдет. первичный загрузчик вызовет только те обработчики для которых найдется их XPATH ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 22:43:38 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
switch, обычно, легко заменяется полиморфизмом, кроме случаев вроде таблицы решений. А полиморфизм легко заменяется свитчем, при это код становится намного понятнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 23:07:15 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪ, только на собеседованиях этого не говорите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 23:33:22 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
только на собеседованиях этого не говорите Наоборот, обязательно говорю. Если такое высказывание шокируют нанимателя, то мне с ним не по пути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2013, 23:35:42 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Йуный джавистЪтолько на собеседованиях этого не говорите Наоборот, обязательно говорю. Если такое высказывание шокируют нанимателя, то мне с ним не по пути. Не всегда собеседуют те, с кем будешь в дальнейшем работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 01:12:03 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Я решил остановиться на таком варианте. В enum описываю все таблицы и все группы. Для каждой таблицы в конструктор передаю объект поведения. У групповых описываю базовое поведение для групп и передаю таблицы, которые входят в эти группы. У всех единый интерфейс, но у конкретных таблиц будет напрямую вызов прогрузки данных, а групповые будут пробегать по своим таблицам и вызывать у них тот же метод, объявленный в едином интерфейсе. Мне кажется оптимальное решение(хоть и много классов) и позволяет избавиться от switch case. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 09:38:58 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanсодержимое разное и обрабатывается по-разному и это вся твоя конкретика? Или у тебя уникальный XML. У всех Node - разное содержимое) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 10:28:14 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdiman, пока ты не расшифруешь РАЗНИЦУ в таблицах АКА свитчах - будет пустой трёп. Забей в XML скрипты DDL\DDL и свитчи не понадобятся)) ЗЫ. Разное поведение, это бизнес-логика. Засунуть её в XML не удастся (дкларативно). Удачи! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 10:31:13 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Потому что я считаю для решения данной задачи конкретика не должна волновать. Я думаю над созданием более высокого слоя чем конкретика каждой ноды. А что там и как будет обрабатываться на данном этапе не должно интересовать и не влияет ни на что ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 10:35:10 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Корееци соответственно обойтись без swicth и т.п. +1 Можно прямо в ноде XML прописать ИмяБЛфункции по обработке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 10:40:26 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
lukdimanПотому что я считаю для решения данной задачи конкретика не должна волновать. Я думаю над созданием более высокого слоя чем конкретика каждой ноды. А что там и как будет обрабатываться на данном этапе не должно интересовать и не влияет ни на что конкретика - это свитч . Я тебе показал без него. swicth - по имени ноды или по какому признаку тебе нужны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 10:42:35 |
|
||
|
Совет по архитектуре компонента
|
|||
|---|---|---|---|
|
#18+
Petro123Можно прямо в ноде XML прописать ИмяБЛфункции по обработке. да! точно! получится Spring IoC ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2013, 11:01:16 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2129796]: |
0ms |
get settings: |
21ms |
get forum list: |
31ms |
check forum access: |
9ms |
check topic access: |
9ms |
track hit: |
92ms |
get topic data: |
25ms |
get forum data: |
6ms |
get page messages: |
113ms |
get tp. blocked users: |
3ms |
| others: | 340ms |
| total: | 649ms |

| 0 / 0 |
