Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
всем доброго дня.

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

Приложение будет проверять счета от поставщиков(например сверка кол-ва и цен).
Счета будут приходить как бумажные, так и в электронном виде.
бумажные будут вбиваться через web, который планируется сделать в ASP.NET (возможно Core).

т.е. проект будет состоять из веб-части и как минимум одного Worker'а, который с Web ничего общего не имеет

мой вопрос в том, насколько богомерзко все эти процессы засунуть в ASP.NET (напрмер запускать их отдельным Thread'ом в Startup.cs)?

Просто, если пойти другим путем(для Worker'ов делать отдельное приложение), то нужно как-то связывать web и процессы(например для оповещения Worker'а о поступлении нового счета).
А это значит или настроить между ними соединение(на ум приходит WCF) или делать каждые пару минут проверку, не появились ли новые счета в БД. В общем ни одно из решений мне не нравится как-то.

Что скажете?
21 дек 16, 13:08    [20031603]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
вот попытался схематично обозначить варианты решений

Картинка с другого сайта.

Картинка с другого сайта.

Картинка с другого сайта.

альтернативные варианты приветствуются

К сообщению приложен файл. Размер - 22Kb
21 дек 16, 13:20    [20031677]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4971
yabs,

Вообще можно по разному. Точнее как вам удобно/умеете.
А так я бы предложил сделать так.

Сделать для проверки счетов отдельное приложение/сервис (СПС).
СПС получает данные из очереди (MS MQ)
Результат проверки пишет в БД и/или отправляет в другую очередь.

Есть "клиенты" веб (для ввода в ручную) и SOAP(для электронного)
Которые отправляют ч/з очередь соответствующие счета в СПС.

Пишется отдельно приложение для просмотра результатов проверки.
Данные берутся из БД и/или очереди.

Где-то так.
Но еще раз повторю. Лучше в начале сделайте как можете/умеете.
Потом делаете рефакторинг. ;-)
21 дек 16, 14:44    [20032175]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
спасибо
хотелось бы сразу все сделать по-хорошему
про MS MQ почитал - интересно
из плюсов отметил, что сообщения не теряются даже в случае временной недоступности адресата
из минусов - по умолчания, я так понял, сообщения передаются только в контексте одного компьютера, для отправки на другие ПК, используется Active Directory?

что вы имеете в виду под СПС?
на тему варианта номер 1, вот набрел на статью http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
значит, кому-то еще приходит в голову такое порно ))
21 дек 16, 16:20    [20032759]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 816
yabs,

IMHO нормальная архитектура должна рассматривать отказоустойчивость.
Если документы в базе данных то они под транзакционным контролем, и взаимодействие с сервисом проще так-же пустить под транзакционный контроль.
Вариант 1/2B: добавленный документ коммитед, комуникациа с сервисом или/сервис недоступен. Как будете востанавливать процесс?
Вариант 2A: вполне рабочий. Можно так-же использовать транзакционную очеред как отдельный компонент для доставки нотификаций к сервису но IMHO в вашем случае преимуществ не вижу а недостатки очевидны: +1 компонента, которую надо поддерживать, синхронный бекап не получите.
21 дек 16, 16:22    [20032765]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
спасибо за мнение
mikron
Вариант 1/2B: добавленный документ коммитед, комуникациа с сервисом или/сервис недоступен.

в варианте 1 как это может произойти?
21 дек 16, 17:06    [20033086]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
mikron,

в варианте 2B предыдущий оратор предложил использовать MS MQ например
21 дек 16, 17:08    [20033095]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 816
yabs
спасибо за мнение
mikron
Вариант 1/2B: добавленный документ коммитед, комуникациа с сервисом или/сервис недоступен.

в варианте 1 как это может произойти?

Элементарно: сервисным процесс завершился по ошибке или просто по сбою питания.
21 дек 16, 17:13    [20033121]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 816
yabs
mikron,

в варианте 2B предыдущий оратор предложил использовать MS MQ например

Конечно можно. Но как будете бэкапить синхронно базу и очередь? А теперь представьте что вам нужно восстановить бэкап. Как будете наполнять очередь?

Я бы взял 2А и если нужно уменьшить задержку в обработке документов, то дополнить его не трензакционным, не персистентным, легковесным возможно даже не гарантированным каналом для оповещения сервиса о поступлении новых данных.
21 дек 16, 17:21    [20033162]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
mikron
yabs
спасибо за мнение
пропущено...

в варианте 1 как это может произойти?

Элементарно: сервисным процесс завершился по ошибке или просто по сбою питания.

вы правы
21 дек 16, 17:40    [20033233]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
mikron
Конечно можно. Но как будете бэкапить синхронно базу и очередь? А теперь представьте что вам нужно восстановить бэкап. Как будете наполнять очередь?

как я себе это представляю:
клиент:
1. сохраняет invoice в БД
2. если коммит без ошибок, то пишем в очередь
сервис:
1. читает сообщение из очереди
2. обрабатывает invoice
3. стирает сообщение из очереди
mikron
Я бы взял 2А и если нужно уменьшить задержку в обработке документов, то дополнить его не трензакционным, не персистентным, легковесным возможно даже не гарантированным каналом для оповещения сервиса о поступлении новых данных.

задержка вообще не волнует
хоть полчаса
P.S. Сеть продуктовых магазинов все равно платит в последний день ))
21 дек 16, 17:45    [20033249]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
yabs,

1. IIS по умолчанию не предназначен для запуска фоновых процессов, он вырубает приложение через 20 минут бездействия, поэтому нужен внешний процесс
2. очередь можно построить либо на реляционной базе данных, либо с использованием MSMQ и аналогов
3. запуск обработки может быть либо по таймеру, либо когда появляются данные

решения:
1.
1.1. загуглите hangfire и аналоги, эта штука будет вызывать фоновые процессы на вашем IIS сервере, что-то вроде планировщика как услуга
1.2. если по каким-то причинам не хочется использовать внешний сервис - обернуть свой планировщик в виндовый сервис, загуглить Quartz.NET или аналоги и использовать в качестве основы
2. я не вижу особой сложности приложения, запредельной производительности, поэтому для простоты необходимо использовать реляционную базу данных как очередь. MSMQ надо изучать, разворачивать, настраивать, использовать провайдеры/библиотеки для доступа к функциям. лишнее звено, тем более, если надо будет синхронизировать данные в БД и в очереди с учетом транзакции - это потенциальная точка риска, а однозначных плюсов я не вижу. делаете таблицу в БД, туда сливаете свои документы, добавите статус (новый, в обработке, обработано), потом запускаете фоновый поток, который будет брать очередные 10-100 записей и обрабатывать их. если понадобится увеличить производительность - запускаете второй поток и синхронизируете доступ к таблице через сериалайзед транзакцию и изменение статуса новый -> в обработке -> обработано
3. по умолчанию планировщик запускает фоновый процесс по расписанию (каждую минуту например), так же желательно предусмотреть, чтобы следующий цикл не запускался, пока не завершится предыдущий. можно предусмотреть внеочередной запуск обработки. этот метод можно будет вызывать из UI, когда например пользователь нажмет кнопку "сохранить"

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

вопросы?
21 дек 16, 20:39    [20033953]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs
спасибо
хотелось бы сразу все сделать по-хорошему
про MS MQ почитал - интересно
из плюсов отметил, что сообщения не теряются даже в случае временной недоступности адресата
из минусов - по умолчания, я так понял, сообщения передаются только в контексте одного компьютера, для отправки на другие ПК, используется Active Directory?

что вы имеете в виду под СПС?
на тему варианта номер 1, вот набрел на статью http://www.hanselman.com/blog/HowToRunBackgroundTasksInASPNET.aspx
значит, кому-то еще приходит в голову такое порно ))

А агрументы есть, почему это порно? :) Годами работает без проблем.
22 дек 16, 09:03    [20035088]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs, нагрузка-то какая предполагается?
22 дек 16, 09:06    [20035096]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA
А агрументы есть, почему это порно? :) Годами работает без проблем.

порно - это я про вариант номер 1
ну потому что IIS создан для хостенья веб-приложений и, как тут уже один из ораторов высказался, по умолчанию он настроен укладывать спать приложение после Х минут неактивности

нагрузка, думаю, смешная будет
в день поступает приблизительно 200-300 счетов
около 20 пользователей
22 дек 16, 11:22    [20035652]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
yabs
нагрузка, думаю, смешная будет
в день поступает приблизительно 200-300 счетов
около 20 пользователей

hangfire или аналог и запускать фоновую задачу после каждого "сохранить", можно передавать ид документа по одному или пачкой
22 дек 16, 12:24    [20035960]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs
skyANA
А агрументы есть, почему это порно? :) Годами работает без проблем.

порно - это я про вариант номер 1
ну потому что IIS создан для хостенья веб-приложений и, как тут уже один из ораторов высказался, по умолчанию он настроен укладывать спать приложение после Х минут неактивности

нагрузка, думаю, смешная будет
в день поступает приблизительно 200-300 счетов
около 20 пользователей

200-300 счетов в день, 20 пользователей? :)

При такой нагрузке никакой worker не нужен. Прилетел файл, сохранили, Task.Run. Всё.
22 дек 16, 15:18    [20037050]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
Да и даже Task.Run не нужен.
22 дек 16, 15:19    [20037060]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
yabs, skyANA
еще бы знать время обработки одного документа
* если будет минута и выше, пользователям будет казатся что сайт/приложение зависло, поэтому было бы хорошо сделать фоновую обработку
* если обработка занимает несколько секунд - то да, делать ее сразу же, и никаких фоновых задач
22 дек 16, 17:02    [20037718]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
17-77
если будет минута и выш

а вы не делайте минуту и выше.
Что можно в БД делать 60 секунд с 4-мя 10-тью ядрами?
22 дек 16, 17:58    [20038051]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
17-77
yabs, skyANA
еще бы знать время обработки одного документа
* если будет минута и выше, пользователям будет казатся что сайт/приложение зависло, поэтому было бы хорошо сделать фоновую обработку
* если обработка занимает несколько секунд - то да, делать ее сразу же, и никаких фоновых задач

ТС пишет: "Приложение будет проверять счета от поставщиков(например сверка кол-ва и цен)".

Это что за счёт такой должен быть, чтобы его больше минуты обрабатывать?
22 дек 16, 19:35    [20038367]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
И даже если минуты, то почему именно фоновый процесс на сервере? На клиенте Web Worker пишется за 15 минут.
22 дек 16, 19:37    [20038373]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
да кто знает что там, может опрос десятка внешних систем по 30 секунда каждая

про веб воркер не знал, не пользовался, не могу ничего сказать, а если случайно браузер закроют - что будет?
22 дек 16, 21:04    [20038688]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
17-77
да кто знает что там, может опрос десятка внешних систем по 30 секунда каждая

про веб воркер не знал, не пользовался, не могу ничего сказать, а если случайно браузер закроют - что будет?

Что-то на схеме нет внешних систем :)

Если браузер закроют, то ничего не будет.
22 дек 16, 21:09    [20038717]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4971
skyANA
ТС пишет: "Приложение будет проверять счета от поставщиков(например сверка кол-ва и цен)".

Это что за счёт такой должен быть, чтобы его больше минуты обрабатывать?


Не счет обрабатывается, а проверка.
Причем не понятно, с какая там будет задержка.
Хорошо если нет связи с внешними системами.
А если есть, а на "той стороне" оператор ручками делает проверку счета. :-)

Но опять же это зависит от конкретной постановки задачи.
Возможно очередь и асинхронная обработка проверки счета это оверинжениринг.
23 дек 16, 08:51    [20039864]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
mad_nazgul
skyANA
ТС пишет: "Приложение будет проверять счета от поставщиков(например сверка кол-ва и цен)".

Это что за счёт такой должен быть, чтобы его больше минуты обрабатывать?


Не счет обрабатывается, а проверка.
Причем не понятно, с какая там будет задержка.
Хорошо если нет связи с внешними системами.
А если есть, а на "той стороне" оператор ручками делает проверку счета. :-)

Ну хорошо, хорошо :) Task.Run

Не вижу необходимость в какой-то очереди и воркере.
23 дек 16, 09:39    [20040037]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
И как-то мы смело решили, что пользователь не готов ждать.

200-300 счетов в день, 20 пользователей. Они их явно не пачками проверяют: отдал одну, пошёл за следующей. :)

Хотя тут можно гадать, что из-за бизнес-процесса оно так.
И сейчас мы коллективно придумает систему, что позволит проверять 2000-3000 счетов в день силами 2-х пользователей (остальных уволить). :)
23 дек 16, 09:46    [20040072]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
mad_nazgul
Хорошо если нет связи с внешними системами.
А если есть, а на "той стороне" оператор ручками делает проверку счета. :-)

связь есть, но именно с системами. никаких операторов.
операторы это как раз те мои 20 пользователей, они будут нужны, когда не сходятся кол-ва в счете и в DWH
или цена в счете и в нашей системе закупок
23 дек 16, 12:10    [20040877]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA
И сейчас мы коллективно придумает систему, что позволит проверять 2000-3000 счетов в день силами 2-х пользователей (остальных уволить). :)

идея и есть в том, чтобы 70-80% счетов проверялась автоматом, без участия человека
и как можно больше счетов приходили электронно(на схеме это отмечено словом EDI)
23 дек 16, 12:12    [20040894]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA
При такой нагрузке никакой worker не нужен. Прилетел файл, сохранили, Task.Run. Всё.

так вопрос не в том, нужен Worker или нет, а в том, как хостить модуль обработки(я его обозвал BACKEND'ом).
Как уже было сказано, счета поступают по 2м каналам: электронно(будут импортированы в БД BACKEND'ом) и ручками в браузере.
23 дек 16, 12:16    [20040921]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
шеф кстати вообще настаивает на вот таком варианте
по идее она самое православное, только мне не хочется делать Мэппинг из Persistence объектов в Business сначала в Backend'е
и потом еще раз в ASP.NET
Картинка с другого сайта.
23 дек 16, 12:22    [20040963]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs, таки в чём проблема сделать единый API, с которым будет работать и то, что Вы называете EDI и то, что у Вас отмечено как ASP.NET in IIS?

API на ASP.NET WebAPI + IIS
23 дек 16, 14:01    [20041624]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs, на чём написан EDI?
23 дек 16, 14:03    [20041633]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
skyANA
Что-то на схеме нет внешних систем :)

ну вон же EDI, там либо документы хранятся (они оттуда поступают, либо их надо скачать), либо данные для сверки, и как вариант там может и не быть веб-клиента - тогда по идее некуда будет пихнуть web worker

yabs
шеф кстати вообще настаивает на вот таком варианте
по идее она самое православное, только мне не хочется делать Мэппинг из Persistence объектов в Business сначала в Backend'е
и потом еще раз в ASP.NET

не будет такого двойного маппинга, бэк-енд отдает всем потребителям (и принимает от них) модели, которые внутри него мапятся один раз (но в обе стороны) на сущности ORM например

бэк-енд как уже сказали - можно в виде WebApi, а можно и wcf отдельный и только на публичные методы для EDI

а тут опять же, если EDI сам документы присылает - это одно, если надо их скачивать оттуда - другое
23 дек 16, 15:20    [20042098]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
yabs
так вопрос не в том, нужен Worker или нет, а в том, как хостить модуль обработки(я его обозвал BACKEND'ом)

модуль обработки хостить как сервис (web-api или wcf)
можно сделать так, чтобы сайт тоже работал с сервисом, но там надо лезть глубже

но нужно еще средство вызова обработки, которое не давало бы сбой, тут три варианта:
1. не делать фоновой обработки вообще (если позволяет время ожидания и скорость алгоритмов и отклика внешних систем) - тогда как только документ поступает каким либо образом в систему - сразу же идет проверка
2. сделать планировщик на сервере (виндовая служба, либо воспользоваться внешним сервисом - hangfire)
3. сделать планировщик на клиенте (web worker), как предложили - но тут мне лично не понятно, а что если файл придет ночью, никто не работает в веб приложении - как воркер запуститься?
23 дек 16, 15:36    [20042182]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
17-77,

По пункту 3 - если документ приходит электронно, то вмешательство человека вообще не требуется.
24 дек 16, 02:31    [20043981]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA
yabs, на чём написан EDI?

EDI это стандарт передачи документов
https://ru.m.wikipedia.org/wiki/Электронный_обмен_данными
Парсер ещё не написан.
24 дек 16, 02:36    [20043983]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
17-77
не будет такого двойного маппинга, бэк-енд отдает всем потребителям (и принимает от них) модели, которые внутри него мапятся один раз (но в обе стороны) на сущности ORM например

Может я чего-то не понимаю, но в варианте 3 у меня будут 3 набора классов:
1. Persistent
2. Business
3. ViewModels
Т.е. Для разработки минус это мэппинг в двух местах
Для быстродействия - лишняя сериализация/десериализация.
24 дек 16, 02:48    [20043988]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
17-77
Member

Откуда:
Сообщений: 1366
yabs,
теоретически можно обойтись только одним набором моделей - типа объекты предметной области, их же использовать в качестве контрактов для сервисов и уровень сериализации/десериализации будет на границе между бэк-ендом и потребителями (EDI/ASP.NET)

эти же сущности можно замапить на таблицы БД через ОРМ, я видел однажды очень хороший пример - довольно сложные сущности, но с помощью замысловатых маппингов с тонкой настройкой это все отражалось в таблицы БД через nHibernate

но на практике постоянно возникают всякие проблемы, то с контекстом ORM, то сущности становятся слишком перегруженными, то с отображением на UI (когда одна сущность имеет несколько экранов с немного разным набором полей для разных ролей пользователей), и т.п.

поэтому делают два слоя - объекты (сущности) предметной области (они же маппятся на БД) и модели для отображения (они же контракты для сервисов), маппинг соответственно между сущностями и моделями, наружу отдают модели, третий по идее лишний
24 дек 16, 10:54    [20044190]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs
skyANA
yabs, на чём написан EDI?

EDI это стандарт передачи документов
https://ru.m.wikipedia.org/wiki/Электронный_обмен_данными
Парсер ещё не написан.

Хм, а почему именно EDI? Что из себя счёт представляет?
25 дек 16, 09:16    [20045839]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA,

Насколько я понял, это распространённый формат у поставщиков.
Причём на него можно весь обмен информацией перевести: заказы, подтверждение, накладные и счета.
25 дек 16, 12:52    [20046099]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
yabs,

Счёт состоит из отправителя, получателя, позиций(кол-во, цена, ставка НДС), конечной суммы и банковских реквизитов.
25 дек 16, 12:58    [20046118]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
yabs
yabs,

Счёт состоит из отправителя, получателя, позиций(кол-во, цена, ставка НДС), конечной суммы и банковских реквизитов.

у 1С более конкретно всё построено на CommerceXML
https://www.sql.ru/forum/319685-4/vybor-alternativy-1s?mid=2960843&hl=1c xml#2960843
а этот EDI что ода вода и одни слова менеджеров.
25 дек 16, 14:02    [20046253]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
Petro123
yabs
yabs,

Счёт состоит из отправителя, получателя, позиций(кол-во, цена, ставка НДС), конечной суммы и банковских реквизитов.

у 1С более конкретно всё построено на CommerceXML
https://www.sql.ru/forum/319685-4/vybor-alternativy-1s?mid=2960843&hl=1c xml#2960843
а этот EDI что ода вода и одни слова менеджеров.

Во-первых, это оффтоп
Во-вторых, EDI это какой-никакой стандарт, в отличие от предложенного вами. Тут как в анекдоте "ради одного засранца трактор заводить не будут"
25 дек 16, 18:28    [20046744]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 26878
yabs, по ссылке, что Вы привели, перечислено 14 стандартов, 8 протоколов и 4 формата.
Вы всё это собираетесь поддерживать?

При том, что "Счёт состоит из отправителя, получателя, позиций(кол-во, цена, ставка НДС), конечной суммы и банковских реквизитов".
ИМХО проще последний распарсить и в электронном виде передать, чем с EDI заморачиваться.
26 дек 16, 07:47    [20047386]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос по архитектуре приложения (ASP.NET, C#)  [new]
yabs
Member

Откуда: 86-78-MEK-L-TR-WI-N
Сообщений: 1376
skyANA,
Из 14 стандартов наверняка используется этот
автор
Стандарт EANCOM используется в торговле

Поддержек всех протоколов реализовать, думаю, не составит труда.

И вообще планы таковы, что формат EDIFACT скорей всего будет конвертироваться во что-то удобоваримое сторонней фирмой


автор
При том, что "Счёт состоит из отправителя, получателя, позиций(кол-во, цена, ставка НДС), конечной и банковских реквизитов".
ИМХО проще последний распарсить и в электронном виде передать, чем с EDI заморачиваться.

Только не парсить, а распознавать отсканированные счета. Удовольствие сомнительное.
26 дек 16, 10:52    [20047904]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Разработка информационных систем Ответить