puppyskyANA,

когда что-то жирное стоит - это неприятно, но не мешает, а вот когда шлется что-то жирное - это плохо )

Если подробнее - ситуация такая:

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

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

ПарамонskyANAпропущено...
Читаю. Пока не вижу с чёго вдруг "там будет некий api".

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

puppyskyANA[А если начать с логирования ошибок? И высылать логи. Сломаться-то может и не на данных, а на отсутсвии прав к примеру.

Ошибки конечно же логгируются. И данные можно и расшарить, и послать. На своем основном месте работы я так все от клиента и получаю. Просто процессы очень сложные, а приложения очень нелепые, поэтому 90 процентов времени уходит на создание условий для повторения ошибки, а 10 процентов собственно на исправление. Поэтому в системе, пишущейся с нуля хотелось бы сразу все сделать максимально просто и удобно и для саппорта, и для клиента
Хм, если считаете, что снятие дампа данных Вам реально поможет, то снимайте его, пакуйте, пересылайте разработчику, пусть заливает в свою локальную базу.

Вот только на мой взгляд это никак не связано с темой и Вашим первым сообщением в топике.
Запилите утилиту dump (export) и утилиту restore (import), чтобы можно их было как из продукта вызывать, так и отдельно.

ПарамонhVosttпропущено...


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

Это как раз хорошо, иначе один сервис перестанет постовлять часть данных, а другие не узнают, а так есть контракт.С чего вдруг сервис перестанет поставлять часть данных? С чего вдруг другие не узнают? Кто это другие?
Хотелось бы конкретики, а не беспредметный спор.

puppyskyANAВот только на мой взгляд это никак не связано с темой и Вашим первым сообщением в топике.

Это точно )

Если по теме, как я понял:
1. Маппингом занимается тот процесс, у которого есть доступ и к сорс, и к дестинейшн классам. Делать маппинг всего-всего в одном месте смысла не имеет

2. Стандартного доступа к хранилищу в виде XML, JSON или чего-то подобного (легкого и человекочитаемого) нет, и тут все сошлись на переносе данных каким-либо образом в нормальную БД, и после этого работы с ней

3. Oracle and MSSQL - как повезет. Либо все впишется в ентити фреймворк, любо придется это разносить на уровне кода

Правильно?Если опустить, мягко говоря, не совсем верные формулировки, то да.