Я всегда считал что в нормальных проектах есть архитектор который придумывает все связи от и до и сверху опускает график UML
Вот нигде такого не встречал. Обычно uml пишут когда уже все готово, для документации. Ибо пока все продумаешь, нарисуешь, уйдет куча времени, а в момент первых же реализаций все может поменяться.
В моем опыте, техдир выбирает стек технологий, в глобальном масштабе решает архитектуру, чаще просто на доске маркером, ставит большие задачи, ведущий - бьет на мелкие задачи и делает пилотный вариант с наброском всех основных слоев. Ну а дальше уже конкретика.
Это же называется прямая (или обратная все время их путаю) геодезическая задача
Не настолько это простая задача, если я не геодезист и с предметной областью слабо знаком.
Первая ссылка по поиску
Первая и по сути единственная) Не поддерживаемая и датированная 2008 г. Но, если ничего не найду, то код от туда себе на заметку возьму.
Я бы взял postgis
В ms sql тоже есть spatial geometry, но использовать его я не могу. Моя задача, можно сказать последняя в конвейере и данные ко мне приходят не из базы и уже предварительно обработанные.
Константин Бердников: Я думаю, что у вас либо нет опыта с Core, либо он не достаточен. На данный момент много компаний, и у нас в том числе, разрабатывают на core и все отлично работает. Да, там нет еще полноценного signalR (лично то, чего нам не хватает), но в остальном претензий нет.
По ссылке код полный бред)) У автора схожие проблемы но ответа на мой вопрос там нет. Зато в комментариях я пошел по ссылке, в которой я получил наводку на решение. Вопрос решен, ответ напишу постом ниже. Вам огромное спасибо за соучастие!
Я в конце поста написал, что это не работает, пробовал. При Image.FromStream(stream) кидает эксепшн о неправильном параметре. Сам content может содержать несколько загруженных файлов и еще инфу о них, потом пары ключей. И как в stream все это разложить на части как раз и не понятно.
Тот CRUD который на dbContext, напрямую в контроллерах используют в небольших тестовых примерах. Тот вариант что Вы описали, да, в примерах или прототипах так и делают, да, entity по сути реализует UoW. В реальных проектах, dbContext оборачивают в свой репозиторий и поверх еще могут сделать свой UoW. Делается это для большей гибкости и возможности писать модульные тесты на те же контроллеры. Если Вы засунете dbContext в контроллер, то Вам останется только интеграционное тестирование. Если у Вас потребуется сформировать какую то модель из более сложной выборки, Вы ее будете делать в контроллере? Вот поэтому чаще это все выносят в отдельный сервис, как я уже сказал напрямую с dbContext работают только в своем репозитории, далее репозитории оборачивают в свой UoW или какой нибудь IDataManager, дальше этот dataManager инжектят в контроллер через конструктор. И получается, что в конструкторе, через эту обертку уже работают с данными. Но чаще этот dataManager инжектят в еще один выделенный слой IService, а уже этот сервис отдают конструктору.
Вообщем, в Вашем варианте так делают, но не в реальных проектах. Потому что получается жесткая связанность entity с контроллером.
Опять не совсем понимаю)) Entity не реализует репозиторий, он таблицы базы мапит в объекты с которыми удобно работать в коде. Если Вы хотите реализовать принцип CRUD, то реализуете это отдельно, где на вход подадите свой dbContext. Свой CRUD можете реализовать через паттерн Repository. В контроллере уже работаете с данными через репозиторий. Если захотите бОльшей абстракции, то можете выделить еще один слой service, в котором уже и будет работа с данными через репозиторий, а сам контроллер будет знать только о сервисе, а не о множестве репозиториев сущностей. Вообще все эти вещи очень хорошо описаны на классических ресурсах .net metanit.com/sharp/mvc.php
Резалтом Вы делаете загрузку синхроной, но она в этом случае не сработает, загрузится только часть файла. Всю цепочку вызовов методов для загрузки файла надо сделать асинхронными.
Если говорить о стандартных не сложных запросов, то Entity уже давно никак не проигрывает по скорости чистому SQL. Это уже все давно протестировалось. Но зато простота и гибкость добавляет существенно.
Вот нигде такого не встречал. Обычно uml пишут когда уже все готово, для документации. Ибо пока все продумаешь, нарисуешь, уйдет куча времени, а в момент первых же реализаций все может поменяться.
В моем опыте, техдир выбирает стек технологий, в глобальном масштабе решает архитектуру, чаще просто на доске маркером, ставит большие задачи, ведущий - бьет на мелкие задачи и делает пилотный вариант с наброском всех основных слоев. Ну а дальше уже конкретика.