по моей практике этот метод гораздо надежней (и меньше велосипедов в виде своих сервисов)Слово "гораздо" создаёт впечатление, что ты помимо VPN реально пробовал использовать сервисы. Пробовал? В чём выражается большая надёжность?
что ты помимо VPN реально пробовал использовать сервисы.Я не знаю как у тебя получилось привязать написанное мною к VPN - я про "гораздо надежней" говорил об обмене данными через стандартные СУБД, а не через "доморощенные" сервисы, которые в большинстве своем реализуют готовый функционал. VPN это по сути "каприз" админов которые по понятным соображениям не хотят открывать прямой доступ к БД (хоть там и по умолчанию так-же стоит шифрованное соединение). VPN в моем случае используется только как "средство доступа", аналогию с SOA в данном случае я не понял. Зачем писать вручную, то что уже прекрасно сделано. Да есть вещи которые реализованы из коробки не на 5 - те-же уведомления (Dependency). Но используя "коробочные" интерфейсы - интеграция с каким-нибудь 1С (или иным "добром") гораздо проще - чем писать еще службу конвертируемую под нее.
Написать свой интерфейс качественно обеспечивающий откат по транзакциям, регулируемый доступ и пр. - это задача не на один год.Это если не на WCF. WCF берёт на себя многое из того, что не относится к уровню бизнес-логики (в т.ч. и транзакции). Реализация по умолчанию подходит для большинства случаев. При необходимости в предлагаемое по умолчанию поведение можно вносить детализированные изменения.
через стандартные СУБД, а не через "доморощенные" сервисы, которые в большинстве своем реализуют готовый функционалСервисы и СУБД - это четыре совершенно разных человека и у них разные задачи. Сервис в процессе своей работы может взаимодействовать с данными, хранящимися в СУБД. Я не ратую за "реализацию готового функционала" (не понимаю, что ты под этим подразумевал). "Доморощенные сервисы" имеет смысл создавать к месту. Тебя же не смущает тот факт, что по сути ты пишешь "доморощенный код"? Так а чем "доморощенные сервисы" отличаются в этом отношении?
не понимаю, что ты под этим подразумевалТак я и пишу - гибкую настройку прав доступа (с администрированием), 100% обеспеченную транзакционную целостность с заданным уровнем блокировок. И потом - даже если все это задавшись целью написать - "администратора" всего этого хозяйства кто будет учить (под известные СУБД их "валом" на hh.ru). Рано или поздно эти требования появляются в любом крупном многопользовательском проекте (я текущий достаточно крупный проект, который на данный момент продаем "за дорого" в другую крупную организацию, тоже начинал с "интерфейса" через XML файлы). Сейчас вся интеграция по данным с информационной системой заказчика представляла из себя выдачу админам (толковые ребята попались - надо отметить) структуры необходимых таблиц СУБД - как-бы это выглядело если все было построено на "своих" сервисах (справедливости ради - так гладко только с данными - что касается второй "большой" части - управления ЧПУ - там такого рода стандарты есть только в зародыше - и пока каждый производитель, кто на что горазд (даже и внутри одного производителя) - по сути приходится не только переписывать функции постобработки, но иногда и менять внутреннею "логистику" производства и создавать дополнительные пользовательские интерфейсы).