Re[10]: Альтернативы EF Core
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 17.08.17 19:32
Оценка:
Здравствуйте, sergeya, Вы писали:

S>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.

S>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.
S>С linq2db можно не бояться джоинов, поскольку он автоматически генерирует схему, включающую и описания таблиц, и связи между ними для легкой навигации parent->child и обратно.
S>И тогда джоин на здание или организацию будет выполняться простым обращением к свойству.

S>
S>_db.User.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })
S>

Зачем условие опустил? Как правило joins и условия являются важной частью бизнес-логики. Достаточно в репозитории сделать приватный метод, который будут использовать публичные, а также будут делать проекции. Вовсе не обязательно ради проекций дублировать по всем сервисам эту бизнес-логику.

S>>Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место. Опять же если вы обратитесь к моему примеру у меня в методе сервиса использовалось 3 репозитория. Чей в таком случае Rollback вызывать? А Commmit. Понятно что для вашего кода это без разницы. Но дизайн кода, что должен думать программист его использующий?

S>>Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.

S>Да, единый коммит и роллбэк будут выполняться через DbNorthwind.

S>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.
А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

S>И чтобы два раза не вставать, вот пример декомпозиции, позволяющий реюзать фильтр пользователей по этажу.


S>
S>IQueryable<UserModel> ApplyFilterByFlat(IQueryable<UserModel> source, int flat)
S>{
S>    return source.Where(u => u.Room.Flat == flat);
S>}
S>


Ничем не отличается от твоего изначального примера. По крайней мере в лучшую сторону. Скорее даже хуже.

S>Теперь этот предикат можно переиспользовать множество раз, комбинируя с другими условиями. И без copy-paste.
Re[11]: Альтернативы EF Core
От: sergeya Ниоткуда http://blogtani.ru
Дата: 17.08.17 19:53
Оценка: +2
Здравствуйте, Spinifex, Вы писали:

Serg>>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.

Serg>>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.

Вот на это что скажешь (см. выше)?

Serg>>С linq2db можно не бояться джоинов, поскольку он автоматически генерирует схему, включающую и описания таблиц, и связи между ними для легкой навигации parent->child и обратно.

Serg>>И тогда джоин на здание или организацию будет выполняться простым обращением к свойству.

Serg>>
Serg>>_db.User.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })
Serg>>

S>Зачем условие опустил?

Добавил условие. Что это меняет?
    _db.User.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })


Показать переиспользование бизнес логики условий? Вот:

var users = _db.User;

users = ApplyFilterByFlat(users, flat);

users = ApplyRowLevelSecurity(users);

users = ExcludeVipUsers(users);

return users.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })


Если озаботиться эстетикой, можно навернуть поверх методы-расширения и организовать method chaining. Но это уже мелочи, не влияющие на принципиальную возможность.

S>Как правило joins и условия являются важной частью бизнес-логики. Достаточно в репозитории сделать приватный метод, который будут использовать публичные, а также будут делать проекции. Вовсе не обязательно ради проекций дублировать по всем сервисам эту бизнес-логику.


Я уже второй пост пишу о том, как в linq2db избавиться от дублирования логики джоинов и условий.

Serg>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.

S>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[12]: Альтернативы EF Core
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 17.08.17 20:06
Оценка:
Здравствуйте, sergeya, Вы писали:

S>Здравствуйте, Spinifex, Вы писали:


Serg>>>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.

Serg>>>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.
S>Вот на это что скажешь (см. выше)?
Я не вижу здесь каких либо препятствий. Это издержки примера, придуманного за 2 минуты. Понятно, что если бы я начал тюнить код, то вытаскивал бы не пользователя, а string с email. Хотя в общем и целом лично я не склонен преувеличивать нагрузку от вытаскивания всей сущности целиком. Да, иногда это действительно заметно и тут надо тюнить. Но в большенстве случаев скорее наоброт ты за один раз вытаскиваешь сущность, части которой потом ниже используешь. Может сложится обратная ситуация, когда ты вместо этого постоянно дергаешь базу ради разных частей одной сущности. Одним словом It depends.

Serg>>>С linq2db можно не бояться джоинов, поскольку он автоматически генерирует схему, включающую и описания таблиц, и связи между ними для легкой навигации parent->child и обратно.

Serg>>>И тогда джоин на здание или организацию будет выполняться простым обращением к свойству.


S>Показать переиспользование бизнес логики условий? Вот:


S>
S>var users = _db.User;

S>users = ApplyFilterByFlat(users, flat);

S>users = ApplyRowLevelSecurity(users);

S>users = ExcludeVipUsers(users);

S>return users.Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })
S>


S>Если озаботиться эстетикой, можно навернуть поверх методы-расширения и организовать method chaining. Но это уже мелочи, не влияющие на принципиальную возможность.


S>>Как правило joins и условия являются важной частью бизнес-логики. Достаточно в репозитории сделать приватный метод, который будут использовать публичные, а также будут делать проекции. Вовсе не обязательно ради проекций дублировать по всем сервисам эту бизнес-логику.


S>Я уже второй пост пишу о том, как в linq2db избавиться от дублирования логики джоинов и условий.

Ну это не прирагатива linq2db Многие так умеют.

Serg>>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.

S>>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

S>Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?

???

DbNorthwind.Query<User>.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })
Отредактировано 17.08.2017 20:07 Nikita Lyapin . Предыдущая версия .
Re[13]: Альтернативы EF Core
От: sergeya Ниоткуда http://blogtani.ru
Дата: 17.08.17 20:39
Оценка: +1
Здравствуйте, Spinifex, Вы писали:

Serg>>>>Ты неправильно мня понял. Я как раз против универсального GetUsersOnTheFlat. Одно дело, когда нужно получить список пользователей на этаже для того, чтобы отправить им почтовое уведомление, а другое дело, когда нужно начислить им компенсацию за не работающий лифт. Или уволить всех скопом.

Serg>>>>Если сделать универсальный метод, возвращающий коллекцию пользователей с полным набором атрибутов, то работать он будет везде неэффективно.
S>Я не вижу здесь каких либо препятствий. Это издержки примера, придуманного за 2 минуты.

Это не издержки примера, а издержки подхода.

S>Понятно, что если бы я начал тюнить код, то вытаскивал бы не пользователя, а string с email. Хотя в общем и целом лично я не склонен преувеличивать нагрузку от вытаскивания всей сущности целиком. Да, иногда это действительно заметно и тут надо тюнить. Но в большенстве случаев скорее наоброт ты за один раз вытаскиваешь сущность, части которой потом ниже используешь. Может сложится обратная ситуация, когда ты вместо этого постоянно дергаешь базу ради разных частей одной сущности. Одним словом It depends.


В учебных примерах — да, вытаскиваем всю сущность. В реальном мире начинаем тюнить.
Интересно, как будет выглядеть этот тюниг в случае с GetUsersOnTheFlat ?

S>>Я уже второй пост пишу о том, как в linq2db избавиться от дублирования логики джоинов и условий.

S>Ну это не прирагатива linq2db Многие так умеют.

Значит согласен, что вариант с linq2db тоже не требует дублирования? Ну OK ))

Serg>>>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.

S>>>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

S>>Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?

S>???

S>DbNorthwind.Query<User>.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })


Так. Что здесь User и что здесь Query<User> ?
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[13]: Альтернативы EF Core
От: sergeya Ниоткуда http://blogtani.ru
Дата: 17.08.17 20:47
Оценка: +1
Здравствуйте, Spinifex, Вы писали:

Serg>>>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.

S>>>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

S>>Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?

S>???

S>DbNorthwind.Query<User>.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })


Это предполагается использовать в UserService вместо вызова organizationRepository.GetUsersOnTheFlat ?

По моему это идет вразрез с защищаемой тобой архитектурой.
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[9]: Альтернативы EF Core
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.08.17 05:48
Оценка: +1
Здравствуйте, Spinifex, Вы писали:

S>Самое главное автору данного кода пришло осознание, что запрос GetUsersOnTheFlat может встречаться более чем в одном сервисе.


Такое на практике — не так чтобы частое явление.

S> И нужно куда-то его вынести, чтобы не делать copy/past.


Ага. И лучше всего — в банальный статический метод.

S>Причем этот запрос гораздо более сложный может быть c джойнами на организацию, на здание, на информацию по зданию и т.п.


А в какой репозиторий будем помещать? В здание или информацию по зданию?

S>Остался вопрос относительно функций Commit(), Rollback(), BeginTransaction(). Им в репозитории совсем не место.


Еще бы. Для него Фаулер придумал Unit of Work.

S>Хорошо бы вынести эти функции в какой-то класс, который абстрагирует нас от DbNorthwind заодно. Но в случае с linq2db это сделать проблематично, т.к. там торчат наружу коллекции сущностей. Зачем-то. Нафига? Никто не знает ответа. Даже автор.


Неправильная постановка вопроса. Обосновывать надо не отсутствие чего то, а необходимость каких то дополнительных сущностей. В частности слоя абстракции. Ты пока так и не объяснил зачем он нужен.

S>Поэтому в сервисах будет DbNorthwind и меньший уровень абстракции, чем мог бы быть.


А что, надо всегда стремиться к максимальному уровню абстракции, даже ценой лишнего boilerplate кода?

S>P.S. Обратите внимание как @Danchik был вынужден упростить код моей функции. У него простая вставка в User. В то время как у меня была работа с тремя репозиториями.


Это плохо?

S> Это как бы намекает какой из подходов используется в реальных боевых проектах, а какой в учебных.


Ну это уж у кого как. Тут главное результат. Есть у меня сейчас два похожих проекта, оба с историей. Один постарше, работает без сбоев и приносит денюжку. Второй — помоложе. Кушает в 3 раза больше ресурсов в облаке и постоянно падает, при том что нагрузка на него сильно меньше. Догадайся, где код попроще, а где изобилует паттернами Фаулера.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[13]: Альтернативы EF Core
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 18.08.17 05:54
Оценка:
Здравствуйте, Spinifex, Вы писали:

S>Я не вижу здесь каких либо препятствий. Это издержки примера, придуманного за 2 минуты. Понятно, что если бы я начал тюнить код, то вытаскивал бы не пользователя, а string с email.


Это не издержки примера, это фундаментальная проблема. Наличие проекций резко снижает вероятность того, что один и тот же запрос понадобится несколько раз. Здесь, на этом сайте неуникальных запросов может с десяток наберется. И несколько сотен — используемых ровно в одном месте. Часто переиспользуются кусочки, строительные блоки: фильтры и expression methods (фича linq2db) в основном.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[14]: Альтернативы EF Core
От: Danchik Украина  
Дата: 18.08.17 08:45
Оценка:
Здравствуйте, sergeya, Вы писали:

S>Здравствуйте, Spinifex, Вы писали:


Serg>>>>>Торчат наружу не коллекции, а IQueriable интерфейсы к таблицам, что позволяет гибко извлекать ровно те данные, которые нужны для конкретного сервиса.

S>>>>А должно торчать DbNorthwind.Query<User>, DbNorthwind.Query<Organization>, DbNorthwind.Query<Message>. Понятна разница?

S>>>Разницу вижу, но не в пользу твоего варианта. Зачем мне целый User, если мне нужен только электронный адрес?

S>>???

S>>DbNorthwind.Query<User>.Where(u => u.Room.Flat == flat).Select(u => new { StreetName = u.Room.Building.Street.Name, OrgName = u.Organization.Name })


S>Это предполагается использовать в UserService вместо вызова organizationRepository.GetUsersOnTheFlat ?


S>По моему это идет вразрез с защищаемой тобой архитектурой.


Все, зацыклились. Репозиторий ради репозитория детектед )
Re[14]: Альтернативы EF Core
От: Spinifex Россия https://architecture-cleaning.ru/
Дата: 18.08.17 16:52
Оценка:
Здравствуйте, sergeya, Вы писали:

S>Это предполагается использовать в UserService вместо вызова organizationRepository.GetUsersOnTheFlat ?

Нет.
Давай я покажу на твоем примере, чтобы было более понятно:
class OrganizationRepository 
{
    public List<User> GetUsersOnTheFlat(int flat) 
    {
        return _db.Query<User>()
            .Where(u => u.Room.Flat == flat)
            .ToList();
    }
}


Теперь, если бы в Linq2Db был бы метод(или свойство) Query. На не нужно было бы менять UnitOfWork при каждом добавлении новой коллекции. В примере я оставил пока еще твой _db. В моем случае это должен был бы быть UnitOfWork. Но по неведомым причинам автор Linq2Db решил сделать очень неудобный дизайн.
Re[15]: Альтернативы EF Core
От: Danchik Украина  
Дата: 21.08.17 15:35
Оценка:
Здравствуйте, Spinifex, Вы писали:

[Skip]

S>Теперь, если бы в Linq2Db был бы метод(или свойство) Query. На не нужно было бы менять UnitOfWork при каждом добавлении новой коллекции. В примере я оставил пока еще твой _db. В моем случае это должен был бы быть UnitOfWork. Но по неведомым причинам автор Linq2Db решил сделать очень неудобный дизайн.


Нормальный дизайн, все сделано чтобы ты мог писать типизированные запросы не ожидая сайд эфектов. Остальное от лукавого.
Если так приспичило наводить абстракции, то есть и реализации этого всего дела (нагуглил) https://github.com/ialekseev/Antler

В основном мои сервисы выглядят так

public static class MyDbHelper
{
   public static IQueryable<Patient> GetPatients(this DataConnection db)
   {
      // фильтруем чтобы случайный человек не добрался куда не надо
      var userId = User.Identity.GetUserId();
      var result = from p in db.Patient
                   join a in db.PatientAssignments on p.PatientId == a.PatientId
                   where a.UserId == userId
                   select p;
      return result;
   }

   public static IQueryable<Patient> GetActivePatients(this DataConnection db, DateTime onDate)
   {
      var result = from p in db.GetPatients()
               where Sql.Between(onDate, p.StartDate, p.EndDate)
               select p;
      return result;
   }
}


Теперь имея только это, я получаю тучу выгод:
  1. Я никогда на ружу случайно не выдам пациента данные которого нельзя видеть. Очень помогает при репортинге.
  2. Могу комбинировать запросы
  3. Сделать агрегацию
  4. Могу вытянуть только ID пациентов, и вся запись тянуться не будет
  5. Одним экспрешином проставить этим записям значение
    db.GetActivePatients().Set(p => p.BeHappy = true).Update();

  6. Могу их удалить (всякое бывает)
    db.GetActivePatients().Where(p => p.IsDisturbing).Delete();

  7. Сдублировать
    db.GetActivePatients().Where(p => p.IsDisturbing).Insert(db.Patient, p => p)();

Думаю не стоит обьяснять сколько кода вам бы пришлось писать используя репозитории?
Игорь когда-то писал что он повыкидал из базы хранимые процедуры и переписал на linq, и наблюдал улучшение производительности всей системы.
Re[15]: Альтернативы EF Core
От: sergeya Ниоткуда http://blogtani.ru
Дата: 21.08.17 15:55
Оценка: +1
Здравствуйте, Spinifex, Вы писали:

S>Давай я покажу на твоем примере, чтобы было более понятно:

S>
S>class OrganizationRepository 
S>{
S>    public List<User> GetUsersOnTheFlat(int flat) 
S>    {
S>        return _db.Query<User>()
S>            .Where(u => u.Room.Flat == flat)
S>            .ToList();
S>    }
S>}
S>


S>Теперь, если бы в Linq2Db был бы метод(или свойство) Query. На не нужно было бы менять UnitOfWork при каждом добавлении новой коллекции. В примере я оставил пока еще твой _db. В моем случае это должен был бы быть UnitOfWork.


Ты не поверишь, но такой метод есть, Только называется он GetTable<T>(). А все эти свойства db.User, db.Room введены для удобства, и внутри вызывают GetTable<>():

public IQueryable<UserModel> User() 
{
    return this.GetTable<UserModel>();
}


По поводу "не нужно менять UnitOfWork при каждом добавлении новой коллекции" — а тип элемента новой коллекции (в твоем приере это User) откуда берется — из воздуха? В моем случае и User и DataConnection генерируется автоматически. И уже не важно, 10 свойств генерируется, или только 9.

S>Но по неведомым причинам автор Linq2Db решил сделать очень неудобный дизайн.


Как видишь, дизайн очекнь удобный. Все предусмотрено )
Мобильная версия сайта RSDN — http://rsdn.org/forum/rsdn/6938747
Автор: sergeya
Дата: 19.10.17
Re[16]: Альтернативы EF Core
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 21.08.17 17:47
Оценка:
Здравствуйте, sergeya, Вы писали:

S>Ты не поверишь, но такой метод есть, Только называется он GetTable<T>(). А все эти свойства db.User, db.Room введены для удобства, и внутри вызывают GetTable<>()


Более того, это вообще не linq2db, а отдельный linq2db.T4Models, который можно как угодно сконфигурить, дописать или вообще выкинуть.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re[3]: Альтернативы EF Core
От: Codechanger Россия  
Дата: 26.08.17 12:13
Оценка: +1
Здравствуйте, Spinifex, Вы писали:

S>Да, но как при этом будет выглядеть код использующий linq2db? Этот вопрос почему-то считается второстепенным по сравнению с вопросом производительности. Хотя он очень важный.

S>Если мне не изменяет память там наружу торчат коллекции объектов. Типа Users, Organizations, Networks. Туда нужно добавлять новые объекты, оттуда забирать нужные. Вопрос авторам. Зачем так ограничевать пользователя linq2db? У ORM есть вся необходимая информация чтобы не вытаскивать это наружу. В этом плане NHibernate сделан очень грамотно. В итоге для NHibernate style мы получаем unitOfWork следующего вида:
S>
S>public class UnitOfWork
S>{
S>    public void Add(Entity object)...
S>    public Entity Get(int id)
S>    public Save()
S>    public Commit()
S>}
S>

S>Который может использоваться разными репозиториями без проблем. UserRepository, OrganizationRepository, NetworkRepository все они принимают в конструкторе unitOfWork. А в случае с linq2db они что принимают? Явная завязка на orm не вариант. Хотелось бы свести ее к минимуму.


ORM головного мозга — штука странная. С одной стороны, хочется писать энтерпрайзно, с другой — чтобы все же было быстро и работало.В целом, от ORM обычно требуются две вещи — маппинг объектной модели на таблицы в базе плюс строгая типизация sql — запросов. Остальное в общем-то от лукавого — change tracking, caching и прочие костыли. В целом, сейчас существуют способы комфортно работать с бд без тяжеловесныъ ORM (EF или, не приведи господи, NHibernate). Ну и разрабатывая на конкретной ORM, становишься заложником технологии невольным — пытаешся доменную модель натянуть на стиль, который предлагается конкретной ORM.
Альтернативы EF Core
От: ionoy Эстония www.ammyui.com
Дата: 31.08.17 14:08
Оценка:
Здравствуйте, Danchik, Вы писали:

D>Linq2db конечно же.

D>https://github.com/linq2db/linq2db

Вопрос к тем, кто реально Linq2db пользуется.

Есть ли best practices для синхронизации базы и кода? Знаю что в BLT раньше были *.tt файлы, которые генерировали код по живой БД. Понимаю, что можно взять одну из библиотек для миграций и использовать её.

Кто чем пользуется?
www.livexaml.com
www.ammyui.com
www.nemerleweb.com
Отредактировано 31.08.2017 14:08 ionoy . Предыдущая версия .
Re: Альтернативы EF Core
От: torvic Голландия  
Дата: 31.08.17 15:27
Оценка:
Здравствуйте, ionoy, Вы писали:
I>Кто чем пользуется?
теми же темплейтами
Re: Альтернативы EF Core
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 31.08.17 21:57
Оценка:
Здравствуйте, ionoy, Вы писали:

I>Есть ли best practices для синхронизации базы и кода?


Есть. Database first или script first.

I> Знаю что в BLT раньше были *.tt файлы, которые генерировали код по живой БД.


В linq2db все тоже самое.

I>Кто чем пользуется?


БД меняю в SSMS на тестовой копии, потом перегенерация моделе1, потом schema compare и апдейт проекта со скриптами. Потом, перед релизом, schema compare с боевой БД и ее реструктуризация.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
AVK Blog
Re: Альтернативы EF Core
От: Danchik Украина  
Дата: 01.09.17 09:46
Оценка:
Здравствуйте, ionoy, Вы писали:

[Skip]

I>Есть ли best practices для синхронизации базы и кода? Знаю что в BLT раньше были *.tt файлы, которые генерировали код по живой БД. Понимаю, что можно взять одну из библиотек для миграций и использовать её.


I>Кто чем пользуется?


Вот так приблизительно и пользуемся
https://www.youtube.com/watch?v=Qc-5UpMYQO0
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.