В таких сценариях она не нужна. Но полезна в следующих примерах:
public class Account
{
...
public double GetTaxes()
{
if (SomeComplexCondition())
{
GetTaxes(this.DomainTrasactions) // load this.DomainTransaction lazily
}
else
{
GetTaxes(this.ForiegnTrasactions) // load this.ForiegnTrasactions lazily
}
}
...
}
Lazy load must have в rich-модели, поскольку пользователь такой модели не имеет никакого представления о проекции данных, которая на самом деле требуется entity для выполнения запрошенной им функции. Конечно, при применении такой функции к листу объектов, автоматически получаем какой-то из вариантов «SELECT N+1»-проблемы. Поскольку EF в настоящий момент не дружит с rich подходом, то и без lazy load вполне можно обойтись.
Поясните, пожалуйста, если мы не используем внешних зависимостей при маппинге (они 100% отправляют нас в ад), то чем не подходит тривиальная инициализания маппингов в bootstrapper-классе? Пока нам не нужно тестировать сами маппинги мне не видно причины, заставляющей нас иметь разную реализацию для теста и приложения той части бутстраппера, которая отвечает за маппинги. Подскажите, где я не прав.
Поведение Вашей реализации репозитория целиком и полностью определяется именно поведением «конкретной технологии доступа к данным» в частности, при добавления в репозиторий entity со связанными entity сохранится весь граф. Это не является типичным поведением репозитория, очевидным из его интерфейса. Наивная реализация интерфейса репозитория на другой «технологии доступа к данным» легко поломает работающее приложение.
«Почему не стоит использовать явно в бизнес-логике конкретную технологию доступа к данным?» в чем тут проблема то? Хотите скрыть persistence от БЛ — скрывайте, но при чем тут репозитарий. Хотите чтобы любая ORM репозитарии представляла — тпк они это давно переросли, на UoW сидят уже. Хотите ужать все ORM до репозитариев и переключать их — на здоровье, если Вам репозитариев хватает. Фронт борьбы давно ушел дальше.
Про мокание
EF нельзя полностью замокать именно потому, что он предоставляет такую функциональность, как Change Tracking, Lazy Loading, In-Memory collections которые поощряют неявное их использование и написание полноценного теста с моками потребовало бы отслеживания кучи вызовов. Поэтому я первым делом указал, что Ваша реализация репозитория «течет» сторонними эффектами и мокание его в простых тестах не означает работоспособность в более сложном сценарии. А течет она из-за того самого change tracking в EF, который как раз и не мешает этот самый EF мокать.
Про расширение.
Да, действительно, если сначала образать EF, то потом получившееся можно расширить. Чем сильнее обрезать, тем проще расширить. Обычно так. Исключения встречаются тоже.
Репозиторий вообщето совсем не спорбый шаблон. А вот занятие по превращению UoW в набор репозиториев — спорное.
Да, таскали негабарит, который иначе пришлось бы или проектировать по-другому или что-то городить с ракетоносителями. Какой именно из модулей — не помню, надо источники смотреть.
Причины неудачи многоразовых систем — обратная сторона стремительного развития микроэлектроники. Ожидалось, что спутники будут большими, дорогими, в частности электроника будет требовать герметичного отсека. Однако спутники стали достаточно малы и дешевы, чтобы починка и возврат шаттлами стали просто невыгодны. Шаттлы проявили себя при обслуживании Хаббла и строительстве МКС. Так что МКС стоит засчитать за выполнение цели по строительству и снабжению орбитальной станции.
Когда придумывали анализ, пространство тоже было только евклидовым и мера казалась естественной и единственной. С тех пор математика на месте не стояла. Посмотрите уже на определение предела последовательности. Там обязательно или используется или мера или топологические св-ва пространства.
Какое это имеет отношение к вопросу недостаточности понятия множества для введения предела на нем? Вы пытаетесь доказать единственность метрики на множестве? Может быть есть такие множества, но R не такое.
Как только Вы этот модуль используете как меру расстояния между числами при определении предела — в этот момент Вы превращаете поле действительных чисел в метрическое пространство, о чем Вам тут уже давно намекают.
Соль увы, не излагается в нескольких абзацах. Просто нужно знать, что мат. анализ, который излагается на первых курсах вузов — это частный случай, однако имеющий широчайшее применение в нашем почти евклидовом приземном пространстве. Понятие метрики (или сразу нормы) применяется уже при определении предела и дальше, таким образом, присутствует в большинстве результатов. Однако даже в нерелятивистской физике иногда нужны другие определения пространства аргумента функции.
Для определения производной нужно вводить понятие предела, а для него обязательно разбираться со свойствами пространства аргумента и того утверждения, что это действительные числа не достаточно. Обязательно потребуется или введение метрики или какое-либо описание топологических свойств. В том определении, которое Вы почему-то считаете единственно возможным, пространство аргумента — это множество действительных числ (непрерывное упорядоченное поле) с метрикой m(a,b) = {b-a при b >= a и a-b в остальных случаях}. Однако даже на том же поле действительных чисел можно ввести другие, например, метрики и получить совсем другие производные.
В данном случае производительность должна быть не «о ужас, ужас» — этого уже достаточно, т.к. reflection при байндинге более узкое место по производительности. Конечно, INPC — это абсолютно точно реализация аспекта императивным программированием. Но пока, увы ни C#, ни VS, как платформа разработки, недружественны к AOP.
Lazy load must have в rich-модели, поскольку пользователь такой модели не имеет никакого представления о проекции данных, которая на самом деле требуется entity для выполнения запрошенной им функции. Конечно, при применении такой функции к листу объектов, автоматически получаем какой-то из вариантов «SELECT N+1»-проблемы. Поскольку EF в настоящий момент не дружит с rich подходом, то и без lazy load вполне можно обойтись.
«Почему не стоит использовать явно в бизнес-логике конкретную технологию доступа к данным?» в чем тут проблема то? Хотите скрыть persistence от БЛ — скрывайте, но при чем тут репозитарий. Хотите чтобы любая ORM репозитарии представляла — тпк они это давно переросли, на UoW сидят уже. Хотите ужать все ORM до репозитариев и переключать их — на здоровье, если Вам репозитариев хватает. Фронт борьбы давно ушел дальше.
Про мокание
EF нельзя полностью замокать именно потому, что он предоставляет такую функциональность, как Change Tracking, Lazy Loading, In-Memory collections которые поощряют неявное их использование и написание полноценного теста с моками потребовало бы отслеживания кучи вызовов. Поэтому я первым делом указал, что Ваша реализация репозитория «течет» сторонними эффектами и мокание его в простых тестах не означает работоспособность в более сложном сценарии. А течет она из-за того самого change tracking в EF, который как раз и не мешает этот самый EF мокать.
Про расширение.
Да, действительно, если сначала образать EF, то потом получившееся можно расширить. Чем сильнее обрезать, тем проще расширить. Обычно так. Исключения встречаются тоже.
Репозиторий вообщето совсем не спорбый шаблон. А вот занятие по превращению UoW в набор репозиториев — спорное.
2. Сводится в п.1
3. Сводится к п.1
4. Снова сводится к п.1
Итого, какая проблама решается «уходом от явного использования DBContext»?