Граждане!
Имею такую проблему.
Есть наша БД, есть куча партнеров со своими БД, и есть обмен данными между этими БД. Суть обмена состоит в пересылке друг другу однотипной информации (например, ФИО, адрес, телефон и т.д.). Связи между партнерами устоявшиеся и все пересылают в чем тока могут (Файлы БД, текстовые файлы, ексель и х.з. что еще). Соответственно никто ничего менять нехочет. В итоге мне шлют кто в чем.
Так вот я хочу сдалать так, чтобы подключение очередного юзера сопровождалось как можно менеьшим геморроем? У меня пока только такая идея (писать на С# буду или на Java):
1. Сделать стандартный способ экспорта/импорта записи БД до состояния объекта.
2. Описать интерфейс с методоми типа записать/прочитать.
3. В нашей БД в соответствие каждому пользователю прописать имя сборки. В сборке класс реализующий этот интерфейс для каждого конкретного дятла.
Таким образом я при подключнии новой клиента я пишу тока ту часть кода, не писать которую все равно низзя и дописываю 1 строку в БД (прописываю сборку).
Может, кто предложет идею получще? Меня гложут смутный сомнения относительно идеальности того, что я понаписал...

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

D>Граждане!
D>Имею такую проблему.
D>Есть наша БД, есть куча партнеров со своими БД, и есть обмен данными между этими БД. Суть обмена состоит в пересылке друг другу однотипной информации (например, ФИО, адрес, телефон и т.д.). Связи между партнерами устоявшиеся и все пересылают в чем тока могут (Файлы БД, текстовые файлы, ексель и х.з. что еще). Соответственно никто ничего менять нехочет. В итоге мне шлют кто в чем.

Это — классический, христоматийный пример ситуации, для которой создавался BizTalk.
Если его использовать по какой-то причине затруднительно, то стоит хотя бы посмотреть на архитектуру. Его или конкурентов.

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

M>Это — классический, христоматийный пример ситуации, для которой создавался BizTalk.
M>Если его использовать по какой-то причине затруднительно, то стоит хотя бы посмотреть на архитектуру. Его или конкурентов.

почитал — вспомнил, как кто-то рассказывал про какую-то фичу (никак не могу вспомнить) типа аддона или плагина к VS которая нужна чтобы конвертить данные каким-то образом. На экране она отображалась как что-то типа блоксхем, при этом во время работы красиво все мигало. И называлось это все как-то типа BDML (Business ... Modeling Language). Я конечно понимаю, на сколько это убогое описание, но мож у кого чтонить шевельнеццо в памяти?..

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

D>Граждане!
D>Имею такую проблему.
D>Есть наша БД, есть куча партнеров со своими БД, и есть обмен данными между этими БД. Суть обмена состоит в пересылке друг другу однотипной информации (например, ФИО, адрес, телефон и т.д.). Связи между партнерами устоявшиеся и все пересылают в чем тока могут (Файлы БД, текстовые файлы, ексель и х.з. что еще). Соответственно никто ничего менять нехочет. В итоге мне шлют кто в чем.
D>Так вот я хочу сдалать так, чтобы подключение очередного юзера сопровождалось как можно менеьшим геморроем? У меня пока только такая идея (писать на С# буду или на Java):
D>1. Сделать стандартный способ экспорта/импорта записи БД до состояния объекта.
D>2. Описать интерфейс с методоми типа записать/прочитать.
D>3. В нашей БД в соответствие каждому пользователю прописать имя сборки. В сборке класс реализующий этот интерфейс для каждого конкретного дятла.
D>Таким образом я при подключнии новой клиента я пишу тока ту часть кода, не писать которую все равно низзя и дописываю 1 строку в БД (прописываю сборку).
D>Может, кто предложет идею получще? Меня гложут смутный сомнения относительно идеальности того, что я понаписал...

Нормальная идея. Когда-то похожее делал на .Net. Следует подумать о едином интерфейсе (API) конфигурирования кля всех плагинов. Ведь каждому из них надо знать, по крайней мере, откуда брать данные. Причем конфигурационная информация для каждого плагина может быть разной, кому то нужно путь и имя файла, а кому-то строка подключения имя и пароль... Опять же пароль..., шифровать надо

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

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

M>>Это — классический, христоматийный пример ситуации, для которой создавался BizTalk.
M>>Если его использовать по какой-то причине затруднительно, то стоит хотя бы посмотреть на архитектуру. Его или конкурентов.

D>почитал — вспомнил, как кто-то рассказывал про какую-то фичу (никак не могу вспомнить) типа аддона или плагина к VS которая нужна чтобы конвертить данные каким-то образом. На экране она отображалась как что-то типа блоксхем, при этом во время работы красиво все мигало. И называлось это все как-то типа BDML (Business ... Modeling Language). Я конечно понимаю, на сколько это убогое описание, но мож у кого чтонить шевельнеццо в памяти?..

Это что ли?

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

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

D>>Граждане!
D>>Имею такую проблему.
D>>Есть наша БД, есть куча партнеров со своими БД, и есть обмен данными между этими БД. Суть обмена состоит в пересылке друг другу однотипной информации (например, ФИО, адрес, телефон и т.д.). Связи между партнерами устоявшиеся и все пересылают в чем тока могут (Файлы БД, текстовые файлы, ексель и х.з. что еще). Соответственно никто ничего менять нехочет. В итоге мне шлют кто в чем.

M>Это — классический, христоматийный пример ситуации, для которой создавался BizTalk.
M>Если его использовать по какой-то причине затруднительно, то стоит хотя бы посмотреть на архитектуру. Его или конкурентов.
Случай действительно хрестоматийный, причем в ситуации, когда никто из контрагентов ничего менять не хочет, конечное решение будет выглядеть весьма забавно. Могучему Бизтолку файлы по папочкам все равно руками расладывать придется, чтоб он их пережевал
Да и стоит Бизталк ох как сильно...

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

D>>почитал — вспомнил, как кто-то рассказывал про какую-то фичу (никак не могу вспомнить) типа аддона или плагина к VS которая нужна чтобы конвертить данные каким-то образом. На экране она отображалась как что-то типа блоксхем, при этом во время работы красиво все мигало. И называлось это все как-то типа BDML (Business ... Modeling Language). Я конечно понимаю, на сколько это убогое описание, но мож у кого чтонить шевельнеццо в памяти?..

M>Это что ли?

Может быть, впринципе похоже, спасибо.

Я бы не стал прогибаться под каждого партнера. И разрешил бы только 2 способа (для гибкости) обмена данными.
1) Через веб-сервис
2) Через эксель (уж в эксель то всегда можно информацию перегнать).

Это если я правильно понял ситуацию.

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

MC>Я бы не стал прогибаться под каждого партнера. И разрешил бы только 2 способа (для гибкости) обмена данными.
MC>1) Через веб-сервис
MC>2) Через эксель (уж в эксель то всегда можно информацию перегнать).

MC>Это если я правильно понял ситуацию.

Вот когда буду дирехтуром, тада я им, мля, всем, покажу! =) А пока делаю что говорят.. =(

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

D>Граждане!
D>Имею такую проблему.
D>Есть наша БД, есть куча партнеров со своими БД, и есть обмен данными между этими БД. Суть обмена состоит в пересылке друг другу однотипной информации (например, ФИО, адрес, телефон и т.д.). Связи между партнерами устоявшиеся и все пересылают в чем тока могут (Файлы БД, текстовые файлы, ексель и х.з. что еще). Соответственно никто ничего менять нехочет. В итоге мне шлют кто в чем.
D>Так вот я хочу сдалать так, чтобы подключение очередного юзера сопровождалось как можно менеьшим геморроем? У меня пока только такая идея (писать на С# буду или на Java):
D>1. Сделать стандартный способ экспорта/импорта записи БД до состояния объекта.
D>2. Описать интерфейс с методоми типа записать/прочитать.
D>3. В нашей БД в соответствие каждому пользователю прописать имя сборки. В сборке класс реализующий этот интерфейс для каждого конкретного дятла.
D>Таким образом я при подключнии новой клиента я пишу тока ту часть кода, не писать которую все равно низзя и дописываю 1 строку в БД (прописываю сборку).
Вариант нормальный, и приэтом, главное, что вы уже понимаете как это сделать.
D>Может, кто предложет идею получще? Меня гложут смутный сомнения относительно идеальности того, что я понаписал...

Думаю не нужно стремиться к идеальному, лутше стремится к решению проблемы.