Я написал этот ответ около четырех лет назад, и мое мнение не изменилось. Но с тех пор на фронте микросервисов произошли значительные события. В конце я добавил заметки для микро-сервисов ...
Я буду взвешивать эту идею, имея реальный опыт, чтобы поддержать мой голос.
Меня привлекло большое приложение, в котором было пять контекстов для одной базы данных. В конце концов, мы удалили все контексты, кроме одного - возвращаясь к одному контексту.
Сначала идея множественных контекстов кажется хорошей идеей. Мы можем разделить наш доступ к данным на домены и предоставить несколько простых и понятных контекстов. Похоже, DDD, верно? Это упростило бы наш доступ к данным. Другой аргумент в пользу производительности - доступ к контексту, который нам нужен.
Но на практике, по мере роста нашего приложения, многие из наших таблиц имели общие отношения в разных контекстах. Например, запросы к таблице A в контексте 1 также требовали присоединения к таблице B в контексте 2.
Это оставило нам пару неудачных вариантов. Мы могли бы дублировать таблицы в разных контекстах. Мы попробовали это. Это создало несколько проблем с отображением, включая ограничение EF, которое требует, чтобы у каждого объекта было уникальное имя. Таким образом, мы получили сущности с именами Person1 и Person2 в разных контекстах. Можно утверждать, что это был плохой дизайн с нашей стороны, но, несмотря на все наши усилия, наше приложение действительно росло в реальном мире.
Мы также попытались запросить оба контекста, чтобы получить нужные нам данные. Например, наша бизнес-логика будет запрашивать половину того, что ей нужно, из контекста 1, а другую половину - из контекста 2. У этого были некоторые серьезные проблемы. Вместо того, чтобы выполнять один запрос к одному контексту, нам пришлось выполнять несколько запросов в разных контекстах. Это реальное снижение производительности.
В конце концов, хорошая новость заключается в том, что было легко исключить несколько контекстов. Контекст предназначен для облегченного объекта. Поэтому я не думаю, что производительность является хорошим аргументом для нескольких контекстов. Я полагаю, что почти во всех случаях один контекст проще, менее сложен и, вероятно, будет работать лучше, и вам не придется реализовывать несколько обходных путей, чтобы заставить его работать.
Я подумал об одной ситуации, когда несколько контекстов могут быть полезны. Отдельный контекст можно использовать для устранения физической проблемы с базой данных, в которой она фактически содержит более одного домена. В идеале контекст должен быть один к одному для домена, который будет один к одному для базы данных. Другими словами, если набор таблиц никоим образом не связан с другими таблицами в данной базе данных, их, вероятно, следует извлечь в отдельную базу данных. Я понимаю, что это не всегда практично. Но если набор таблиц настолько отличается, что вам будет удобно разделить их на отдельную базу данных (но вы не захотите), тогда я мог бы рассмотреть возможность использования отдельного контекста, но только потому, что на самом деле есть два отдельных домена.
Что касается микросервисов, единый контекст все еще имеет смысл. Однако для микроуслуг каждый сервис будет иметь свой собственный контекст, который включает только таблицы базы данных, относящиеся к этому сервису. Другими словами, если служба x обращается к таблицам 1 и 2, а служба y обращается к таблицам 3 и 4, каждая служба будет иметь свой собственный уникальный контекст, который включает в себя таблицы, специфичные для этой службы.
Мне интересны ваши мысли.