Antonariy,

Смысл? Code First этого когда код пишешь, потом БД генерируется. А у тебя уже БД есть ))

Агнец за бортом,

Ого

Агнец за бортомAntonariy,

Почему не создать .NET проект, воссоздать код классов CF из готовой DB, а затем перенести его (код) в CORE?

Всё равно не понятно, зачем ему Code First, при наличии готовой СУБД. Если Code First не используется как Code First, то зачем такое вообще надо? Database First и все дела.

AntonariyОна перерабатывается чуть более чем на половину, и будет переноситься с MSSQL на другие СУБД.

Тогда тебе нужно Model First.

Antonariyа что насчет переносимости сгенеренных классов из .net в core?

Ты про .NET Core, или EF Core?

AntonariyhVosttпропущено...


Ты про .NET Core, или EF Core?я про это: 20678555

Я так не делал, не знаю :0

ViPRoshVostt,

есть такая фигня - https://www.codeproject.com/Articles/1160615/Generating-Code-for-EF-Core-with-CatFactory

Всё равно, до сих пор не понимаю смысла :)

Code First это же миграции. А если БД уже есть, надо лишь продолжить её существование, то как бы первой миграции не должно быть. Это можно сделать конечно, там есть ключик, но это ломает подход.

Наверное лучше всё же Model First. На мой взгляд сугубо.

ViPRos,

Да они все об одном и том же: статичная схема данных, проста выбирается точка, где схема будет изменяться: в коде, в модели или в бд. Зависит от того, кто к чему привык. Мне нравится подход из кода, так я могу разрабатывать вообще не открывая СУБД, просто указал коннекшен стринг и забыл. Есть проект у нас, такой не очень большой, я БД в глаза не видел чё там внутри, просто создавал классы, генерировал миграции из кода. И это работает на отлично. Никаких косяков ни разу не было.

Но сейчас, конечно, мы уже отошли от этого :) У нас сразу 3 разных СУБД (Postgres, Mongo, ElasticSearch), и EF со своими шашечками пролетает.

AntonariyТо есть ЕF не используете?

Только в проектах на поддержке, ещё активно используем. В новых пока нет.

Petro123как-то противоречиво)
hVosttИ это работает на отлично. Никаких косяков ни разу не было.
hVosttНо сейчас, конечно, мы уже отошли от этого :)

Не противоречиво, EF отлично справляется со своими задачами. Но у нас уровень задач вырос, и EF уже не подходит.

Используем Dapper для работы с SQL.

Antonariyне понял, в нем нужно пейсать текстовый sql-говнокод?

Dapper работает чисто с SQL, да.
Означает ли это, что его надо писать вручную?
Вовсе нет :)
Кто мешает написать свой SqlBuilder? Задачка-то не сложная.
Хотя могут быть такие SQL, которые лучше написать вручную, полностью или частично.

Antonariy,

Мы используем CQRS/ES. Все таблицы в SQL полностью динамические, т.е. изначально там вообще нет ни одной таблицы. По мере добавления агрегатов, добавляются таблицы, для реализации Read Model. Поэтому EF нам тут никак не поможет ничем.

ViPRosлучше вообще не пользоваться data class и тогда нафиг и этот даппер не нужен будет

Не понимаю о чём ты.

ViPRosможет, если модель ваш влезает в EDM, то можно EDM налету сгенерировать и пользоваться EF, чем всякие недоделки в виде дапперов

Недоделка в виде даппера используется в реализации StackOverflow, они же её и сделали.
Наша модель не может использоваться в EDM, так как создаётся в рантайме, а SQL база воссоздаётся и ведётся из событий. Миграция тоже событие.

ViPRosу меня модель не влезает EDM, да и РМ тоже (из за агрегатных ссылочных типов - это типа "Сборочная единица" = Union(Изделие, Деталь, ПКИ, Материал,...,Заготовка). Мало того - этот агрегат динамичен.

Ну тогда, ты понимаешь о чём я. Правда у нас агрегат это понятие из DDD, а у тебя какое-то собственное понятие

ViPRosи еще много чего со ссылочными типами, пересекающимися схемами 9макротипы) и т.д.

У нас любой бизнес-тип, это инфо-тип. Ссылочный тип, это всего лишь один из типов системы инфо-типов. Ссылка это всегда идентификатор на агрегат. Так как идентификаторы уникальны, мы можем чисто по ID найти любой, не зная ни типа, ни таблицы, ничего. Только ID. Аналогия такая же, как в .NET имея ссылку на Object, ты можешь получить GetType() и делать свои дела.

ViPRosнадо еще какой то слой сверх-рядом с ЕДМ :(
но можно все же взять ЕДМ и сваять сверху свой слой - все же лучше наверное было бы - за счет поддержки ЕФ многих провайдеров

EDM это про статическую модель.

Тем более, у нас сейчас SQL это чисто только READ, никаких операций пользовательских INSERT или UPDATE нет вообще в принципе. Только SELECT и точка. Зачем над EDM?

ViPRosагрегат у меня - это некоторое множество ваших инфотипов (они и же просто типы и они ж ссылочные типы)
то что по ИД можно вычислить тип и т.д., означает наличие громадного лукапирущего типа - Объект, что воще то чревато, трудно вести его :(

Нет никакого громадного лупапирующего типа. Это простая возможность, мы её не планировали, просто получили нахаляву :)

Инфо-тип у нас тоже агрегат.

ViPRosну значит либо система мало должна писать, либо будет работать медленно

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


ViPRosEDM можно генерировать в рантайме и пользовать

Ну какой смысл EDM в райнтайме? EDM это типизация, смысл которой только исключительно в разработке. В рантайме нафиг не упёрлась.

AntonariyЕсли избыточность генерируется - не вопрос. А если говнокодится руками? Это же время, которое - деньги. Хорошо, когда и времени и денег выше крыши, но обычно это не так. Приходится идти на компромиссы.

Я имел в виду избыточность данных, а не избыточность кода. Кода, кстати, получается на порядки меньше, чем если бы ту же задачу мы решали классическим способом, через EF. И с течением времени, количество порядков растёт. Например, добавили 50 сущностей, с логикой, валидацией, формочками, со сложной безопасностью, с проверками, с полноценной историей с откатами, и... не написали ни строчки кода, ничего не компилировали, не перевыкладывали. Нужные таблички в SQL создались, в ElasticSearch создались индексы для поиска.