Должен ли я добавить одну и ту же таблицу в ограниченном контексте нескольких сущностей
У меня довольно большая база данных, около 80 таблиц или около того. Поэтому я решил разделить таблицы в ограниченный контекст вместо того, чтобы иметь все 80 таблиц в одном большом файле EDMX.
Поэтому я ограничил контексты, такие как продажи, клиенты и т. Д.
У меня есть основная таблица клиентов в файле edmx клиентов. Однако мне также нужно получить доступ к определенным полям, не ко всем, но к 1 или 2 полям (например, мне просто нужно имя клиента, а не весь объект / таблица клиента) из таблицы клиентов из контекста Sales edmx.
Должен ли я добавить всю таблицу клиентов в файл Sales edmx? Какова лучшая практика для этого сценария?
3 ответа
У этого подхода есть пара основных проблем:
EF, как и любой ORM, попадает в постоянную проблему. Как таковая, она не должна мешать структурированию вашей доменной модели. Тот факт, что все ваши сущности сохраняются в том, что звучит как одно хранилище постоянных данных, может указывать на то, что ваши ограниченные контексты перекрываются или не существуют.
Попытка перейти к лучшей структуре - это не плохо:) - однако, как отметил Марк Орета, я, вероятно, не стал бы беспокоиться о структуре EF.
Основная проблема, с которой вы сталкиваетесь, связана с попыткой чтения из модели вашего домена. Кажется, это слишком часто встречается в системах, и это делает вещи довольно сложными. Ленивая загрузка является прямым результатом именно этого. Когда вы читаете, в идеале вы должны использовать слой запросов с доступом к хранилищу запросов (может быть, к той же базе данных), которое оптимизировано для чтения. В вашем примере вам нужно денормализованное имя клиента в вашем домене продаж. Это хорошо. Попытка получить это, читая модель вашего домена, а затем пытаясь извлечь данные из модели домена в другом ограниченном контексте, - вот что причиняет вам боль.
Если вы пойдете по пути разделения ваших данных, вам нужно будет их разделить.
Хотя данные из разных BC могут находиться в одном и том же хранилище, вы должны думать о своих данных, как будто каждый BC имеет свою собственную базу данных. Иногда у меня есть один проект с различными проблемами (от слоев до нескольких) в разных папках / пространстве имен (здесь.NET). Должно быть возможно разделить эти проблемы на отдельные собрания по прихоти. Поэтому они не должны быть слишком тесно связаны. То же самое касается структуры данных, которую вы пытаетесь разделить. По сути, вы должны быть в состоянии выделить соответствующие данные БК в отдельную базу данных. Механизмы получения данных через BC - это другой вопрос, и я думаю, что если это не удастся решить, вы можете столкнуться с трудностями.
Хотя я не думаю, что идентификация BC со стороны данных может быть лучшей идеей, это, безусловно, шаг в правильном направлении:)
Мне нравится взгляд Джули Лерман на эту тему http://msdn.microsoft.com/en-us/magazine/jj883952.aspx
Я использую ограниченные контексты для производительности доступа, так как время загрузки контекстов быстрее при использовании меньших dbcontexts даже при использовании сгенерированных представлений. Простая модель доступа - это хорошо. производительность рассмотрите советы на сайте MS ef: http://msdn.microsoft.com/en-us/data/hh949853
BC также предоставляют другие преимущества, такие как ограничение доступа, чтобы соответствовать бизнес-проблеме. Большие проблемы возникают, если вы пытаетесь работать с контекстами БД, которые различаются не только тем, в каком наборе DBSet появляется, но и тем, как вы пытаетесь изменить представления модели. Я думаю, что это лучше всего делать вне EF и наносить на карту.
Я использую один большой контекст SUPERSET для управления созданием / переносом БД. Но не ежедневный доступ.
Меньшие DB contexts используются для ежедневного доступа к данным в течение всего дня.
Так что да, во что бы то ни стало, используйте ограниченный контекст. Это может быть против того же хранилища данных. И чтобы ответить на вопрос в следующей редакции: "Да, одна и та же таблица (DbSet) может появляться во многих контекстах.
Если вы хотите иметь возможность доступа к сущности Customer из вашей сущности Sales с помощью свойства навигации, (Sale.Customer) вам нужно добавить его в edmx продаж.
Нет ничего плохого в том, чтобы все ваши таблицы были в одном edmx, если вы их создаете, используете его для нужных вам действий, а затем утилизируете его, граф объектов не станет таким большим.
В качестве альтернативы, если вы хотите сохранить ограниченные контексты, у вас может быть хранилище или что-то, извлекающее его по идентификатору, когда вам это нужно.
var customer = customerContext.GetCustomerById(sale.CustomerId);