T>Если я правильно понял, то сервисный слой включал в себя объектную модель приложения (ии ее вообще не было, а были DataSets), и в T>тоже время средства для работы с базой? Не совсем понятно зачем смешивать перпендикулярные вещи в одном слое? T>Хранение данных лишь один из аспектов приложения. По мне, так всю бизнес логику пихать в РСУБД которая T>изначально предназначена для хранения и выборки данных не самое лучшее решение. Хотя бы потому, что T>бизнес-логика в хранимых процедурах это гарантированный vendor-locking. Да и поддерживать горы SQL-кода сложнее, T>чем тоже писанное на ООП языке.
Не совсем... Этот слой осуществляет именно вызов хранимых процедур... Ну предположим есть таблица USER и соответствующий ему класс, есть операции с объектами этого класса. В данном случае сервисный слой взывает все хранимые процедуры с ним связанные, будь-то выборка или сохранение, часть операций возвращает не только наборы данных, а, возможно просто числа или ничего не возвращает вообще. Для всех операций, которые должны возвращать коллекцию объектов User осуществляется маппинг (он вполне может быть автоматическим с использование собствтенной библиотеки) и строка из НД преобразовывается в объект. Для операций, которые не возвращают данных.... При этом сама вызываемая процедура обновления данных может быть сколь угодно сложной....
Ну допустим так: данные о пользователях не только можно изменять, но и сохранять историю изменений, при этом есть две даты "с" и "по" — в случае последней записи дата "по" пустая. При обновлении такой записи необходимо передать не только новые значеия полей, но и идентификатор пользователя, который изменил в хранимую процедуру, которая "закроет" прошлую запись и "откроет" новую.
T>Hibernate, EJB(Entity), JDO это в большей мере средства абстрагирования объектной модели приложения от конкретного хранилища данных, это может быть реляционная БД (здесь и нужен ORM), объектная БД, обычный XML-файл в конце концов. Если вам нужна сверхвысокая производительность на специальных запросах или хотите работать на низком уровне используйте JDBC напрямую. Зато JDO, Hiberanate помогут вам перенести приложение на другую БД без особых проблем, предоставят возможности по декларативному управлению транзакциями, кэшированием и др. полезными вещами.
Абстрагироваться от хранилища?! А Вы действительно считаете это возможным??! (в этом случае я говорю про БОЛЬШУЮ систему — Переход от от MS SQL к Oracle будет очень проблематичен и все равно займет много времени и денег, а особенно, когда все размыто в коде...., для этого должна быть очень существенная причина) А оно надо?! И Вы действительно считаете, что система, которая обслуживает ОЧЕНЬ много запросов и итак работает на кластере (16,4-х процессорных) с более-менее приемлимой производительностью, тосле такого "абтсрагирования" не "умрет"?!
Мой сервисный слой органиован в виде COM+ компонентов, поэтому там также декларативное управление транзакциями.
Или может с подобным в Java туговато? Здесь поподробнее, пожалуйста.....
