Различные представления древовидной структуры + локализация - Архитектура программного обеспечения

Есть некая древовидная структура объектов представляющих собой различные сущности, например структура такая :

Город
     string Название
     array  Организации[]
              |-enum  Тип Организации { ООО, ЗАО, ... }
              |-array Сотрудники[]
                               |-enum Пол {Муж, Жен}
                               |-date Год Рождения

Далее задача построить различные древовидные модели в зависимости от выбора пользователя, например следующие :

Москва(1)
  |----ЗАО(100)
         |--Муж(100000)
              |-1969(50000)
              |-1970(50000)
         |--Жен(100000)
  |----ООО(1000)

потом может потребоваться например такое представление

Муж(1)
   |--1969(150000)
       |---Москва(100000)
       |---СПБ(50000)
   |--1970(150000)
       |---Москва(100000)
       |---СПБ(50000)
Жен(1)

И т.д. Цифры в скобках — количество элементов с данным значением, то есть группировка по значению.

Вот собственно вопрос — какой лучше сделать универсальный интерфейс для элементов дерева чтобы можно было обеспечить необходимую гибкость в представленнии элементов ?

И второй вопрос — как лучше организовать локализацию элементов. Например,

enum Gender { 
              [SomeAttribute( "не определен" )]  
              Undefined, 
              [SomeAttribute( "мужской" )]
              Male, 
              [SomeAttribute( "женский" )]
              Female 
};

[SomeAttribute( "Cотрудник" )]
сlass Worker
{
  [SomeAttribute( "Пол" )]
  Gender gender;
}

Смущает использование аттрибутов и Reflection для получения строкового представления элемента что приведет к существенному снижению производительности.
еще вижу вариант следущий — в ресурсах Ru-RU.resx, En-en.resx описать примерно следующим образом :

Gender.Undefined    "не определено"
Gender.Male         "мужской"
Worker              "сотрудник"
Worker.gender       "пол"

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

Здравствуйте, Аноним, Вы писали:

А>Есть некая древовидная структура объектов представляющих собой различные сущности, например структура такая :

А>

А>Город
А>     string Название
А>     array  Организации[]
А>              |-enum  Тип Организации { ООО, ЗАО, ... }
А>              |-array Сотрудники[]
А>                               |-enum Пол {Муж, Жен}
А>                               |-date Год Рождения

А>

А>Далее задача построить различные древовидные модели в зависимости от выбора пользователя, например следующие :

Если у вас даные в базе, то используйте OLAP.

G>Если у вас даные в базе, то используйте OLAP.

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

Здравствуйте, Аноним, Вы писали:

А>И второй вопрос — как лучше организовать локализацию элементов. Например,
А>

А>enum Gender { 
А>              [SomeAttribute( "не определен" )]  
А>              Undefined, 
А>              [SomeAttribute( "мужской" )]
А>              Male, 
А>              [SomeAttribute( "женский" )]
А>              Female 
А>};

А>[SomeAttribute( "Cотрудник" )]
А>сlass Worker
А>{
А>  [SomeAttribute( "Пол" )]
А>  Gender gender;
А>}
А>

А>Смущает использование аттрибутов
Напрасно

A>и Reflection для получения строкового представления элемента что приведет к существенному снижению производительности.
"К существенному снижению производительности" -- это сколько в процентах по вашим замерам?

А>еще вижу вариант следущий — в ресурсах Ru-RU.resx, En-en.resx описать примерно следующим образом :
А>

А>Gender.Undefined    "не определено"
А>Gender.Male         "мужской"
А>Worker              "сотрудник"
А>Worker.gender       "пол"
А>

А>но данный вариант также получается низкопроизводительным

Предлагаю вам скомбинировать -- локализацию хранить в ресурсах, и привязывать ее атрибутами (в атрибутах указывать ключи ресурсов [дефолтных/из сателлитной сборки, как обычно]).

enum Gender { 
              [SomeAttribute( "Gender.NotDefined" )]  
              Undefined, 
              [SomeAttribute( "Gender.Male" )]
              Male, 
              [SomeAttribute( "Gender.Female" )]
              Female 
};

Здравствуйте, meowth, Вы писали:

А>>Смущает использование аттрибутов
M>Напрасно

A>>и Reflection для получения строкового представления элемента что приведет к существенному снижению производительности.
M>"К существенному снижению производительности" -- это сколько в процентах по вашим замерам?

Спасибо. Видимо мои представления о Reflection устарели ) работает с аттрибутами практически без издержек.

Остается теперь придумать как бы подобие OLAP реализовать )

А>Город
А>     string Название
А>     array  Организации[]
А>              |-enum  Тип Организации { ООО, ЗАО, ... }
А>              |-array Сотрудники[]
А>                               |-enum Пол {Муж, Жен}
А>                               |-date Год Рождения

А>

А>Далее задача построить различные древовидные модели в зависимости от выбора пользователя, например следующие :

А>

А>Москва(1)
А>  |----ЗАО(100)
А>         |--Муж(100000)
А>              |-1969(50000)
А>              |-1970(50000)
А>         |--Жен(100000)
А>  |----ООО(1000)
А>

А>потом может потребоваться например такое представление
А>

А>Муж(1)
А>   |--1969(150000)
А>       |---Москва(100000)
А>       |---СПБ(50000)
А>   |--1970(150000)
А>       |---Москва(100000)
А>       |---СПБ(50000)
А>Жен(1)
А>

А сами сущности у вас имеют постоянную структуру, или тоже динамические?

Здравствуйте, Аноним, Вы писали:

А>Есть некая древовидная структура объектов представляющих собой различные сущности, например структура такая :

[skipped]

Не уверен, что поможет, тем не менее...
Для такого формата данных выглядит естественным хранить его в XML.
Скорее всего, должны быть соответствующие классы для хранения таких объектов, да и способы представления данных, когда они будут в XML.

Здравствуйте, Sergey T., Вы писали:

ST>А сами сущности у вас имеют постоянную структуру, или тоже динамические?

Да структура одинакова. Количество объектов создаваемых за один сеанс с контрагентом относительно не велико , не более 50 000. Наполнение данных разное.

Впринципе известно также что иерархия =3 уровня. Подтягивать для этого СУБД и OLAP как-то не совсем хочется, сильно утяжеляет решение и его развертывание. В крайнем случае думаю захардкодить 6 комбинаций представлений ( 1,2,3 ; 1,3,2; 2,3,1; 2,1,3; 3,1,2; 3,2,1 ), если нет архитектурных решений. Хотя задача на мой взгляд должна быть из разряда "классика", но я с теорией плохо знаком к сожалению

А>Город
А>     string Название
А>     array  Организации[]
А>              |-enum  Тип Организации { ООО, ЗАО, ... }
А>              |-array Сотрудники[]
А>                               |-enum Пол {Муж, Жен}
А>                               |-date Год Рождения

А>

А>Москва(1)
А>  |----ЗАО(100)
А>         |--Муж(100000)
А>              |-1969(50000)
А>              |-1970(50000)
А>         |--Жен(100000)
А>  |----ООО(1000)
А>

А>потом может потребоваться например такое представление
А>

А>Муж(1)
А>   |--1969(150000)
А>       |---Москва(100000)
А>       |---СПБ(50000)
А>   |--1970(150000)
А>       |---Москва(100000)
А>       |---СПБ(50000)
А>Жен(1)
А>

А>И т.д. Цифры в скобках — количество элементов с данным значением, то есть группировка по значению.

А>Вот собственно вопрос — какой лучше сделать универсальный интерфейс для элементов дерева чтобы можно было обеспечить необходимую гибкость в представленнии элементов ?

Я б делал так — сваливал данные из изначальной структуры в некую условную "таблицу", типа такого (или с бОльшим числом колонок, не важно):

City   |DOB  |Gender  |CompanyType |Count 
-------+-----+--------+------------+-----
Москва |69   |М       |ЗАО         |50000

Затем, сделал бы в таблице что-то вроде метода collapse, который возвращал бы другую таблицу, у которой удалена какая-либо колонока, и соответственно увеличен Count для оставшихся строк. Сложность этой операции будет примерно O(n*ln(n)+n) = (отсортировать по удаляемой колонке)+(пройти по строкам таблицы и построить новую)
Затем совершенно тривиально делаем сортировку для строк в соответствии с группировкой по полям, т.е. для первой модели сортировка идет по (city, CT, Gender, DOB), а для второй — (Gender, DOB, City)
После сортировки деревяха строится в один проход по таблице.
Соответственно в модели у нас лежит эта таблица, которую в зависимости от выбора пользователя мы пересортировываем (со сложностью примерно O(m*n*ln(n), где n — число строк, m — число полей, по которым идет сортировка), берем из нее деревяху и показываем.

Или я не понял вопроса?
А>И второй вопрос — как лучше организовать локализацию элементов.
Присоединяюсь к уже высказанной идее в атрибутах хранить ключи из ресурсов, а не строки

Здравствуйте, komaz, Вы писали:

K>Я б делал так — сваливал данные из изначальной структуры в некую условную "таблицу", типа такого (или с бОльшим числом колонок, не важно):
K>

K>City   |DOB  |Gender  |CompanyType |Count 
K>-------+-----+--------+------------+-----
K>Москва |69   |М       |ЗАО         |50000
K>

K>Затем, сделал бы в таблице что-то вроде метода collapse, который возвращал бы другую таблицу, у которой удалена какая-либо колонока, и соответственно увеличен Count для оставшихся строк.

это собственно и есть OLAP. никакие спецсервера для таких объёмов данных понятно не нужны

	От:	Аноним
	Дата:	09.07.09 07:24
	Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	09.07.09 07:32
Оценка:

	От:	Аноним
	Дата:	09.07.09 07:37
	Оценка:

	От:	meowth
	Дата:	09.07.09 08:00
	Оценка:

	От:	Аноним
	Дата:	09.07.09 10:37
	Оценка:

От:	Sergey T.	http://overstore.codeplex.com
Дата:	09.07.09 16:41
Оценка:

	От:	BulatZiganshin
	Дата:	10.07.09 15:03
	Оценка:	+1