- Get started для EF (EF core as for future) - посмотреть как работать и устанавливать
- Planning Pocker - download and prepare to implement ORM
- Unity get started from Sergey
про деплой - притвориться админом с пустой машинкой (поднять вируалку с виндой). Есть простой проект asp .net hello world в студии. Как локально развернуть его на своей локальной машине?Как задеплоить этот проект на другой машине? Как взять виртуалку и развернуть путем скрипта? https://docs.microsoft.com/en-us/powershell/module/webadministration/?view=win10-psзадеплоить node.js приложение также как c#
поднимаем windows server virtual box, скрипт нужен на настройку окружения и деплой приложения, в нашем случае с билдовой машины на окружение код загружается
(мы с дженкинса берем)
берем дженкинс как запускатор
Удаляем предыдущий сайтец и деплоем новый
ORM Concept
Learn the purpose (what is solved, how it looks without them). - конспект на выходе
Implement simple ORM to generate queries.
Learn existing implementations (EF is mandatory), compare them.
ORM (Object-Relational Mapping) или объектно-реляционный проектор — ОРП
I. Цель / что было до
ORM - «технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования»…
ORM — прослойка между базой данных и кодом который пишет программист, которая позволяет складывать / получать в/из базы данных созданные в программе объекты.
ORM это способ задания связи объектов и РСУБД, который позволяет абстрагироваться от способа хранения объектов, с лёгкостью переходя от SQL к NoSQL, memcache, файлам или REST/RPC API на удалённом сервере, оперируя на уровне модели (если говорить о MVC и т. п.) простыми plain old objects, а их персистентность отдать контроллеру.
ORM не исключает обращение к БД на уровне произвольных SQL запросов, он лишь преобразует результаты этих запросов в объекты модели предметной области (и наоборот), которые в идеале ничего не знают о таблицах, WHERE, HAVING....
ORM - инструмент архитектурного разделения областей ответственности объектов и классов приложения, а также инструмент облегчения разделения труда разработчиков (кто разбирается в SQL работает по «ту сторону» ORM; кто хорошо разбирается в дебетах и кредитах — работает с plain old objects в терминах предметной области).
Какую проблему решает
Если вы должны загружать или вставлять данные в SQL, вы должны замапить свои .NET типы данных в SQL. Для .NET это означает использование ADO.NET для отправки SQL команд к SQL-серверу. Затем нам надо отобразить SQL типы в .NET типы (которые могут отличатся друг от друга (например, даты)).
ADO.NET помогает нам в этом, но оставляет нам работу по обработке сырых наборов данных и созданию объектов .NET. В итоге мы получаем что хотим — мы работаем с объектами и типами .NET. А какой-то код транслирует это в SQL запросы и обратно.
ORM предназначены решать эту проблему, добавляя слои различных абстракций поверх ADO.NET.
отвязываешься от конкретной базы, ты абстрактен и тебе не важно какая реализация.
маппинг типов
абстрагируемся от sql
Обработка сырых наборов данных и создание объектов
** Тестирование поверх ORM, где есть репозиторий
Стратегии ORM
I. Прямое отображение сущностей (Entity-based relational mapping)
В таком отображение почти всегда таблицы базы данных соотносятся 1:1 с сущностями в вашей системе. Когда вы добавляете свойство к объекту — добавляете и колонку к таблице. Использование такого способа строится вокруг загрузки сущности / агрегата по его идентификатору, управлению этим объектом и, возможно, связанными объектами, а затем сохранения этого объекта в базу данных посредством ORM.
ORM в этом случае предоставляет множество функционала, например:
• Слежение за изменениями
• Ленивая загрузка
• Предзагрузка (eager fetching)
• Каскадность
• Обеспечение уникальности объектов
• Работа с единицами работы (Unit of work)
Если работать с одной сущностью / агрегатом одновременно, такие ORM как NHibernate очень подходят.
Пока мы загружаем объект с единственной целью изменить его, всё работает отлично. Обратная сторона такого подхода в том, что ORM не знает, собираетесь ли вы только читать объекты, или загружаете сущность, чтобы изменить её.
II.Отображение в наборы данных (Result-set-based relational mapping)
В большинстве приложений, требования к чтению данных существенно превосходят количество записей.
SQL хорош в работе с данными в сетах (наборах). Чтобы выбрать какой-то набор данных из SQL сервера, часто не имеет никакого смысла пытаться прямо отображать эти данные в сущности, но предпочтительно не работать напрямую с DataTable. Это плохо-типизированные объекты, тяжело переносимые в верхние слои приложения. Наоборот, часто строятся объекты, приспособленные к данным. Эти объекты часто называется DTO (Data-Transfer Objects), или модели для чтения (Read Models). Такие DTO мы создаём для индивидуальных SQL выборок — и редко для того, чтобы повторно использовать их в других запросах.
Этот подход не очень хорошо работает, если нам надо применить бизнес правила и сохранить информацию обратно. Так как эти модели обычно отображаются в отдельные наборы данных, а не в таблицы базы данных.
III. Отображение DML-запросов (DML-based relational mapping)
Если вы знаете, какой SQL вам нужен для реализации CRUD, и предпочли бы создавать его вручную, то вы уже ищите что-то, чтобы эффективно аббстрагировать DML команды на уровень выше, чем ADO.NET.
И это арена микро-ORM. Такие фреймворки как PetaPoco, Dapper, Massive и другие созданы, чтобы помочь решить проблемы работы ADO.NET. Они обычно всё равно позволяют нам работать с объектами ADO.NET, но наше взаимодействие сильно упрощается. Нам только нужно соединение, и эти фреймворки могут позволить работать со всеми CRUD операциями в виде, который предлагает намного более простой код, чем сам ADO.NET.
IV. Инструменты массовой загрузки (Bulk loading tools) Иногда вы не хотите вставлять/загружать данные объектным способом. Вместо этого, вы бы предпочли работать со всеми наборами целиком. Утилиты работают примерно как базука, вырывая все данные сразу туда и обратно, но не предоставляя ничего кроме этого. Вы не можете обновлять или удалять данные, но для того, чтобы получить большие объёмы данных из SQL, эти утилиты — то что нужно.
Утилиты намного быстрее традиционных методов парсинга/загрузки данных.
Implementations
Nhibermate
Использует указанную конфигурацию для слежения за загруженными сущностями и автоматическим сохранением изменений во время коммита транзакции. Мы не должны таскать за собой свой слой работы с данными. NHibernate делает всю грязную работу за нас.
Единственный оператор SQL на три десятка строк, выполняющий нечто посложнее выборки по ключу, потребует для достижения того же результата в разы, если не на порядок, больше строк на C#.
Такая ситуация приводит разработчиков ORM к необходимости создавать собственный SQL-подобный язык для манипуляции объектами и уже его транслировать в сиквел (HQL — Hibernate Query Language – SQL-подобный язык запросов, используемый в Hibernate/NHibernate ). Или использовать непосредственно SQL с динамическим преобразованием результата в коллекцию объектов.
В противном случае прикладной программист обречён на извлечение из БД и последующую обработку больших массивов данных непосредственно в своём приложении.
Entity Framework
Открытый для просмотра orm фреймворк от asp .net команды. Позволяет абстрагироваться от самой базы данных и работать с данными независимо от типа хранилища. Если на физическом уровне мы оперируем таблицами, индексами, первичными и внешними ключами, но на концептуальном уровне, который предлагает Entity Framework, работаем с объектами. Центральной концепцией является понятие сущности или entity. Сущность представляет набор данных, ассоциированных с определенным объектом.
Плюсы Entity Framework
- Highly featured
- Open source
- Комплексные sql запросы с использованием Linq
- Works well with microsoft technologies (e.g. asp.net mvc, asp.net identity)
Минусы Entity Framework
- Cons of EF 6
- Speed issues (solved in EF Core 1)
- Hard to read generated sql queries
- Not yet Highly featured as EF 6 (we expect to be solved in the next year)
- Domain modeling approaches