none
Архитектурное решение RRS feed

  • Вопрос

  • Планируется ПО в процессе эксплуотации которого периодически будут изменяться печатные формы и комичество полей в обмене данными с другими ИС. Разработка на C#. Вопрос какие решения заложить при планировании такого приложения.  
    13 апреля 2011 г. 9:10

Ответы

  • Вопрос такой - какие решения заложить при планировании такого приложения? Из каких соображений их использовать.

    вы пишете ***вначале надо определиться каким образом проходит обмен.*** Вопрос как определиться со способом обмена?

    Вы пишете *** Экспорт происходил в виде DBF файла.***

    Во многих случаях используется XML, и т.д..

    Честно говоря я надеялся, что есть некие конкретный рекомендации по такой "стандартной" архитектуре приложения.

    В моем случае я просто изучил документацию по целевой ИС, в которой было сказано, что импорт у данной системы производится по средствам DBF файлов. Поэтому он и использовался.

    Вы можете использовать формат XML, он довольно широко используется для импорта и экспорта в различных ИС.

    Импорт и экспорт - это довольно индивидуальные подходы, не имеющие довольно влиятельного отношения к архитектуре приложения. Форматы же будут скорее общепризнанными и рекомендованными, чем тоже жестко стандартизированными. Так что, изучите те ИС с которыми будет необходим обмен данными и посмотрите какие форматы они поддерживают для экспорта данных и эти форматы Вам надо будет реализовывать для импорта в Вашей ИС.

    Сделайте слой доступа к данным и заложите в него помимо стандартного функционала, функционал для экспорта и импорта данных извне.

    P.S.: Импорт и экспорт - это не архитектурное решение. Это требования к функционалу ИС.


    [My blog] [My E-mail]
    • Помечено в качестве ответа Abolmasov Dmitry 25 апреля 2011 г. 8:28
    19 апреля 2011 г. 7:28

Все ответы

  • Посмотрите в сторону Crystal Report. И не зашивайте шаблон отчета в программу, а сделайте его подгружаемым из вне. В Crystal Report отчет формируется на основе запросов в БД, таким образом шаблоны не зависят напрямую от приложения. А зависят от источника данных. Это дает вам гибкость для дальнейших изменений отчетов(шаблонов).

    Как осуществляется обмен данными с другими ИС? Какие стандарты и протоколы?


    [My blog] [My E-mail]
    15 апреля 2011 г. 9:41
  • Поведение программы, с точки зрения обмена данными, обновлений модулей, будет аналогично программам сдачи электронной отчетности. Мне бы хотелось получеть рекомендации по данному архитектурному решению.

    16 апреля 2011 г. 4:09
  • Поведение программы, с точки зрения обмена данными, обновлений модулей, будет аналогично программам сдачи электронной отчетности. 

    Я не могу понять, а в чем собственно Вы хотите получить рекомендации? Опишите подробно проблему и чего вам не понятно =)

    Вы не можете понять на какие модули разделить программу?

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

    P.S.: Мне приходилось писать инструмент для экспорта данных из одной ИС (самописной) по персонифицированному учету в другую (Документы ПУ 5, в которой сдавалась отчетность). Экспорт происходил в виде DBF файла. Его же потом просто импортировали в целевую ИС. И целевая ИС (Документы ПУ 5) сама загружала все данные в свою БД.


    [My blog] [My E-mail]
    • Помечено в качестве ответа Abolmasov Dmitry 19 апреля 2011 г. 3:15
    • Снята пометка об ответе SlotDB 19 апреля 2011 г. 4:30
    16 апреля 2011 г. 8:08
  • Вопрос такой - какие решения заложить при планировании такого приложения? Из каких соображений их использовать.

    вы пишете ***вначале надо определиться каким образом проходит обмен.*** Вопрос как определиться со способом обмена?

    Вы пишете *** Экспорт происходил в виде DBF файла.***

    Во многих случаях используется XML, и т.д..

    Честно говоря я надеялся, что есть некие конкретный рекомендации по такой "стандартной" архитектуре приложения.

     


    19 апреля 2011 г. 4:37
  • Вопрос такой - какие решения заложить при планировании такого приложения? Из каких соображений их использовать.

    вы пишете ***вначале надо определиться каким образом проходит обмен.*** Вопрос как определиться со способом обмена?

    Вы пишете *** Экспорт происходил в виде DBF файла.***

    Во многих случаях используется XML, и т.д..

    Честно говоря я надеялся, что есть некие конкретный рекомендации по такой "стандартной" архитектуре приложения.

    В моем случае я просто изучил документацию по целевой ИС, в которой было сказано, что импорт у данной системы производится по средствам DBF файлов. Поэтому он и использовался.

    Вы можете использовать формат XML, он довольно широко используется для импорта и экспорта в различных ИС.

    Импорт и экспорт - это довольно индивидуальные подходы, не имеющие довольно влиятельного отношения к архитектуре приложения. Форматы же будут скорее общепризнанными и рекомендованными, чем тоже жестко стандартизированными. Так что, изучите те ИС с которыми будет необходим обмен данными и посмотрите какие форматы они поддерживают для экспорта данных и эти форматы Вам надо будет реализовывать для импорта в Вашей ИС.

    Сделайте слой доступа к данным и заложите в него помимо стандартного функционала, функционал для экспорта и импорта данных извне.

    P.S.: Импорт и экспорт - это не архитектурное решение. Это требования к функционалу ИС.


    [My blog] [My E-mail]
    • Помечено в качестве ответа Abolmasov Dmitry 25 апреля 2011 г. 8:28
    19 апреля 2011 г. 7:28
  •  ****С помощью импорта и экспорта? Или обмен происходит по средствам сетевых протоколов и последующей передачей необходимых данных из одной ИС в другую?****

    Я указывал в начале, что ПО планируется.

    Может есть где сравнение/рекомендации.

    ***Вы можете использовать формат XML***

    Очевидно это так, везде говорится, что это современный стандарт, при периодическом обмене данными.

    При динамическом обмене предлагается DDE http://msdn.microsoft.com/en-us/library/ms648774(v=vs.85).aspx   (мне так кажется).

    *****в процессе эксплуотации которого периодически будут изменяться печатные формы и комичество полей в обмене данными****

    По моему это накладывает архитектурные требования. Начиная с БД заканчивая модулями системы.

    Приветсвуются любые идеи :-).

     

    19 апреля 2011 г. 12:14
  •  ****С помощью импорта и экспорта? Или обмен происходит по средствам сетевых протоколов и последующей передачей необходимых данных из одной ИС в другую?****

    Я указывал в начале, что ПО планируется.

    Может есть где сравнение/рекомендации.

    ***Вы можете использовать формат XML***

    Очевидно это так, везде говорится, что это современный стандарт, при периодическом обмене данными.

    При динамическом обмене предлагается DDE http://msdn.microsoft.com/en-us/library/ms648774(v=vs.85).aspx   (мне так кажется).

    *****в процессе эксплуотации которого периодически будут изменяться печатные формы и комичество полей в обмене данными****

    По моему это накладывает архитектурные требования. Начиная с БД заканчивая модулями системы.

    Приветсвуются любые идеи :-).

    То что Ваше ПО еще только планируется - это понятно. НО! Ваше ПО должно уметь обмениваться данными с другими, уже существующими ИС. Поэтому Вам необходимо вначале изучить эти ИС и их механизмы обмена данными, так как они будут приоритетными для взаимодействия систем. Эти механизмы не всегда являются регламентированными. Как следствие Вам возможно придется реализовывать целый ряд подходов к обмену информацией.

    На мой взгляд начинать надо с этого. А уже на следующем этапе прорабатывать регламентированные подходы к обмену данными в ИС.

    Печатные формы в идеале должны зависеть только от источника данных. Как следствие, в ИС должен присутствовать модуль построения аналитики, который уже подгружает со стороны шаблоны отчетов.

    Динамический обмен данными в формате DDE - это хорошо. Но повторюсь, убедитесь вначале, что другие ИС тоже его поддерживают. А то может получиться, что какой-либо реализованный функционал Вашей ИС будет просто не востребованным. Те его наличие будет неоспоримым преимуществом вашей ИС, но только одного его наличия мало, надо, чтобы этим пользовались. Составьте список приоритетов подходов, а уже потом принимайтесь за их реализацию.

    В идеале надо начинать проектирование системы с того что составить список требований к функционалу системы. После чего можно переходить к построению логической модели базы данных. Далее можно переходить к проектированию ИС. Разбиению ее на модули, конструированию макетов форм и тд.


    [My blog] [My E-mail]

    19 апреля 2011 г. 12:31
  • Вам бы патерны проектирования почитать. 

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

    Святослав дал вам даже схематическое описание модулей! А Вы говорите, что решили проблему обмена информацией с помощью импорта текстовых файликов в SQL. Извините, но это отборный бред и нестыковка. Наймите толкового архитектора чтобы спроектировал систему - в выигрыше будут все.

     


    Don't forget to mark the correct answer Blog
    19 апреля 2011 г. 15:15
  • Вам бы патерны проектирования почитать. 

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

    Святослав дал вам даже схематическое описание модулей! А Вы говорите, что решили проблему обмена информацией с помощью импорта текстовых файликов в SQL. Извините, но это отборный бред и нестыковка. Наймите толкового архитектора чтобы спроектировал систему - в выигрыше будут все.

     


    Don't forget to mark the correct answer Blog

    Спасибо за рекомендацию о прочтении книги пары десятков книг, я уверен, что это универсальный ответ на любой вопрос форума. Что про колесо, так о ТЗ в 230 стр. и про диаграмму классов ни кто не спрашивал. Я понимаю, что обмен данными это наверно такая уникальная задача, что при вопросе об этом никто конкретно ничего сказать не может, почемуто. и вот эту книгу я тоже читал

    http://apparchguide.ms/

    Ответа на данный конкретный вопрос я там не обнаружил. Что касается найма толкового архитектора - спасибо. Только по моему здесь тоже толковые люди есть, а оценивать толковость архитектора через полгода, когда приходится переделывать 1/3 ПО это не очень здрово, опыт имеется.

    Но за совет спасибо.

    19 апреля 2011 г. 19:33
  • Ответа на данный конкретный вопрос я там не обнаружил. Что касается найма толкового архитектора - спасибо. Только по моему здесь тоже толковые люди есть, а оценивать толковость архитектора через полгода, когда приходится переделывать 1/3 ПО это не очень здрово, опыт имеется.

    Как я уже писал выше, импорт и экспорт - это не архитектурное решение. Это требования к функционалу ИС. Книга же та написана про рекомендации к архитектурным подходам при проектировании приложений.

    Изучите внимательно Ваше ТЗ, решите в каком виде будет поставляться ваш продукт. И уже потом выбирайте архитектуру. После чего уже производите распределение функционала по модулям, а модули уже распределяйте по слоям.

    Данный вариант использования системы (импорт, экспорт) напрямую взаимодействует с данными, как следствие располагаться этот функционал должен внутри слоя доступа к данным. Модуль формирования аналитики, должен располагаться в слое бизнес-логики. Откуда уже подготовленные для визуализации данные поступают в слой представления, откуда их уже видит пользователь.

    Если Вы с чем-то конкретным не согласны, то говорите с чем, а то у Вас как-то все расплывчато.


    [My blog] [My E-mail]
    19 апреля 2011 г. 19:44
  • 1. ТЗ в 230 стр. и про диаграмму классов ни кто не спрашивал.

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

    1. Откуда в ТЗ появилась диаграмма классов, если не секрет? Она вроде как разрабатывается на этапе проектирования приложения. По крайней мере я с другими подходами не сталкивался.

    2. Обмен данными - это не уникальная задача. Это задача индивидуальна из-за специфики функционирования разных ИС. Если Вы хотите, чтобы Ваша ИС была удобной, то Вам действительно необходимо изучить спектр всех возможных ИС, с которыми необходимо обеспечивать взаимодействие.


    [My blog] [My E-mail]
    19 апреля 2011 г. 19:54
  • Уже закончил

    http://social.msdn.microsoft.com/Forums/ru-RU/fordataru/thread/e886d04c-8c75-4f27-9f64-4e873622fb1c/
    http://social.technet.microsoft.com/Forums/ru-RU/scrlangru/thread/6aa9acee-51a0-412c-8989-47ae914e4b51/

    теперь рассматриваю данный вопрос в комплексе.

    Поясняйте подробно, что теперь Вы хотите из всего этого сделать. Здесь не экстрасенсы. Так будет меньше споров и больше дела.

    Ну перенесли вы данные из текстовых файлов в БД. И что? А причем тут ИС, которую Вы хотите разрабатывать? Хотите чтобы то что вы сделали в предложенных выше топиках могла делать Ваша ИС?


    [My blog] [My E-mail]
    20 апреля 2011 г. 10:00
  • SlotDB, есть ли у Вас какие-либо результаты? Не забывайте отписываться.
    [My blog] [My E-mail]
    22 апреля 2011 г. 12:21