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

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

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

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

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

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

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


crud entity-framework wcf soa data-access
person MrLane    schedule 02.03.2010    source источник
comment
Зачем развертывать собственную службу вместо использования службы данных WCF? Он предоставляет вам некоторые функции, которых, по вашему мнению, не хватает в вашем сервисе, и его реализация чрезвычайно не требует больших усилий, если у вас уже есть модель EF.   -  person Craig Stuntz    schedule 02.03.2010

Ответы (1)


arrow_upward
7
arrow_downward

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

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

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

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

person Ryan Brunner    schedule 02.03.2010