Добрый вечер,

есть следующая задача:

1. Некий сервис, обрабатывающий данные
2. Данные для сервиса могут быть либо в MSSQL, либо в Oracle, либо в XML файле, либо в их неком сочетании (XML + MSSQL or XML + Oracle)

Есть начал писать решение, которое состоит из следующий проектов:

1. DAL - там доступ к базе (пока это только MSSQL, доступ к XML не пробовал, доступ к ораклу - частично)через ентити фреймворк
2. BLL - там сервисы для веб морды + для рантайм сервиса
3. Рантайм сервис
4. Веб UI

Несколько вопросов по этому безобразию:

1. Пока ентити фреймворк одинаково нормально работает и с MSSQL и с оракл. Натолкнусь ли я на какие-то особенности оракла, что мне придется доступ к этим базам разносить на разные проекты? Логики никакой в базе не предполагается, только таблицы для хранения

2. Есть ли что-нибудь стандартное для работы с XML файлами в качестве хранилища? Или надо делать что-то свое? Если таковое имеется, наверное есть смысл вынести все классы описывающие таблицы в отдельный проект (чтобы эти же классы использовать для доступа к нодам XML?

3. Как тут правильно конфигурить автомаппер? По логике, все мапы должны быть заданы при запуске верхнего приложения (веб морды или сервиса). Но конечное приложение не имеет ссылки на DAL (ни сервис, ни веб интерфейс), т.е. для установки маппинга между Domain Model and DTO Model придется в приложениях верхнего уровня добавлять ссылки на DAL в конечных приложениях, что не совсем правильно. Или сделать отдельный проект, который будет заниматься исключительно маппингом и для интерфейса и для веба?

Поделитесь своими мыслями / опытом, заранее спасибо

hVostt,

Есть необходимость запускать приложение у разработчика с клиентскими данными и без развернутой базы. Соотвественно, вариант - у клиента нажать на кнопку и выгрузить все в какой-то формат, у разработчика - запустить сервис с этими данными (без базы). XML - не обязательное требование, можно поменять на JSON (ничего про это не знаю, почитаю). К нему есть стандартные интерфейсы доступа?

По поводу автомапера.
Ок, он динамический, на основании профайлов. Но все равно в классе профайла должен быть доступ и к сорс и к дестинейшн. Соответственно профайл, где маппинг между dto и viewmodel может быть в web проекте, а вот маппинг между domain model и dto model? В сервисах? Т.е. два места, где маппинг определяется?

ViPRos,

чувствуется богатая предыстория у этого слова тут )))

hVosttSQLite и другие встраиваемые СУБД. XML -- наихудший выбор.

Ну данных мало, по 2-3 записи из 10-15 таблиц, целую базу (хоть и компактную) слишком жирно пересылать, мне кажется

hVosttподключать через Autofac-модули или другие подобные механизмы.

Про autofac можно поподробнее (он все равно у меня используется)? В сервис модуле autofaca добавить маппинги для соответствующей сервисной сборки? Или что-то другое имелось в виду?

skyANA,

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

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

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

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

Petro123у него есть желание переписать систему под себя лбимого)).


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

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

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

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

Это точно )

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

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

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

Правильно?

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

А какие формулировки неверные? Еще и с устрашающим "мягко говоря" префиксом?

Парамон, hVostt,

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