WCF SOA: служба доступа к данным CRUD ... зачем (или наша конструкция ошибочна)?

Question

В нашей системе SOA WCF есть служба доступа к данным. Этот сервис отвечает за выполнение операций CRUD (создание, обновление, удаление) над таблицами базы данных «всей системы», а также является источником этих данных для запросов. Любой другой сервис в системе, желающий получить доступ к таблицам под управлением DAS, должен обратиться к DAS, чтобы получить или изменить его. Мы используем Entity Framework и создали собственную систему отслеживания состояния POCO для этого DAS.

В нашей базе данных есть другие таблицы, которые принадлежат отдельным службам и хранят данные только для их собственного использования, то есть информацию о состоянии, к которой они могут получить доступ в случае сбоя, возобновления или записи деловой информации. У нас есть правило, что любая одна таблица не может быть доступна более чем одной службе: поэтому данные, необходимые для нескольких служб, попадают в DAS.

Правда, я никогда не понимал, почему служба доступа к данным - хорошая идея, а не просто прямой доступ к таблицам. Кажется, что это происходит медленнее, наш DAS не является транзакционным, так как он не может отправить обратно граф POCO для обновления базы данных (только один POCOS за раз), и у нас также возникают проблемы, когда DAS фактически является клиентом для другой службы, которая нуждается в данных от этого ... круговая зависимость.

Зачем беспокоиться о DAS? Почему DAS так важен, когда речь идет о SOA? Что мне здесь не хватает? Единая точка контроля?

Является ли также недостатком разработки SOA, что не все таблицы являются частью DAS и что некоторые службы имеют свои собственные "частные" таблицы?

Любое обсуждение этого приветствия.

Answer 1

Вы правы, думая, что это правильный способ делать вещи, и вы также правы, что это замедляет ход событий и может иногда быть громоздким. SOA обязательно обменивается некоторой эффективностью в обмен на обеспечение единых точек контроля для всех данных, связанных с сервисом. На самом деле, даже идея иметь «общий DAS-сервис» немного воняет в некоторых кругах SOA.

Централизовав все операции CRUD для одной службы в приложении SOA, вы можете обеспечить целостность данных и правильное выполнение бизнес-правил. Чтобы привести пример, подумайте о сущности, которую вы хотите сохранить, с которой связаны некоторые бизнес-правила, к которым трудно обратиться с точки зрения чистого SQL - например, скажем, таблица, в которой хранятся ссылки на файлы, и создайте / обновите сервисы, обеспечивающие существование этих файлов.

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

Еще одним преимуществом является масштабируемость и удобство обслуживания. Допустим, одна из ваших служб имеет доступ к огромному массиву данных. С SOA все «черный ящик», так что ваш клиентский код не имеет большого знания о том, как данные в конечном итоге получаются. Вы можете изменить свою СУБД, таблицы разделов или внедрить кэширование и сделать все это невидимым для вызывающего его клиентского кода - гарантируя, что ваши болезненные обновления нужно делать только в одном месте. Поскольку код базы данных разбросан по всему приложению, такое обновление становится чрезвычайно болезненным.