API для использования SQL-шаблонов
Работу с SQL-шаблонами будет осуществлять специально написанный унифицированный объект 2nd tier. А в ASP стандартная библиотека Project ASP API будет предоставлять удобную оболочку (адаптер) для этого объекта. Пусть этот адаптер называется EntityManager. Упрощенно, он должен предоставлять все те же 4 DML функции: SELECT, UPDATE, INSERT, DELETE. Часто предлагается использовать другие названия, чтобы подчеркнуть, что это уже не SQL, а абстрактная сущность уровня бизнес-логики. "SELECT" называют, например, "Get", "UPDATE" -> "Amend", "INSERT" -> "New" или "Create", "DELETE" -> "Remove". Ограничения, также, накладывает используемый язык программирования. Например, в JScript "delete" является зарезервированным словом и его нельзя использовать как имя.
"SELECT" можно разделить на 2 метода. Один возвращает единичную строку выборки. А второй возвращает объект-итератор, через который можно получить многострочную выборку. В JScript и PerlScript достаточно просто реализуется динамическое создание нового типа объекта и его возврат как результат метода. В обоих случаях "SELECT"-методов, атрибуты возвращаемого объекта будут соответствовать OUT-переменным SQL-шаблона. А, в случае многострочной выборки, объект будет дополнительно содержать стандартные, для итератора, методы next() и eof(). Никто не запрещает также предложить другие удобные в работе методы.
Вот пример списка методов класса EntityManager:
| selectOne(entity_name, template_name, arg1, arg2, ..., argN) | Этот метод получает имя сущности, имя шаблона и список входных параметров шаблона. Как результат, возвращается объект, содержащий выходные параметры шаблона в виде своих атрибутов. В JavaScript это реализуется при помощи функции eval(): например так: s = "this.sFirstName='"+sFirstName+"';\n"; s += "this.sLastName=... ... obj = eval("new function(){ "+s+" } "); return obj; Все эти механизмы скрывает адаптер EntityManager. Он взаимодействует с 2nd tier объектом, который может передавать сразу все полученные атрибуты в виде пригодной для eval() строки. Таким образом будет экономится время на вызовы 2nd tier (все атрибуты будут получены одним вызовом) и на формирование JScript-объекта. |
| selectSet(entity_name, template_name, arg1, arg2, ..., argN) | Этот метод возвращает объект-итератор, атрибуты которого аналогичны описанным для selectOne(), а методы стандартны для итераторов: next(), eof(), и close() |
| selectAttr(entity_name, template_name, arg1, arg2, ..., argN) | Возвращает значение первого выходного параметра шаблона (для простейших SELECT-выражений, выбирающих 1 значение) |
| exists(entity_name, template_name, arg1, arg2, ..., argN) | Возвращает TRUE/FALSE при наличии/отсутствии результирующих строк у SQL-шаблона типа SELECT |
| update(entity_name, template_name, arg1, arg2, ..., argN) | Реализует DML-команду UPDATE |
| insert(entity_name, template_name, arg1, arg2, ..., argN) | Реализует DML-команду INSERT |
| remove(entity_name, template_name, arg1, arg2, ..., argN) | Реализует DML-команду DELETE |
| close() | деструктор объекта EntityManager |
Вышеописанные методы имеют переменное число аргументов, что совсем не является проблемой для Perl, а в JavaScript массив аргументов метода объекта (внутри этого метода) получается через запись this.имя_метода.arguments;
Очень часто более сложную бизнес-логику для операции с сущностями абстрактно можно свести к одной из 4х вышеупомянутых DML команд - SELECT, INSERT, UPDATE, DELETE. И так же нужно передать входные и получить выходные параметры. А это означает, что мы можем использовать одинаковую форму записи вызовов к SQL-шаблонам и к сложным операциям бизнес-логики 2nd tier. Корректную переадресацию вызовов инкапсулирует EntityManager, действуя в зависимости от имени шаблона. Например, вызов SQL-шаблона сущности Shop, типа INSERT, c именем "NewShop", может переадресовываться сложному объекту 2nd tier, создающему новый экземпляр сущности Shop и выполняющий соответствующие действия. Основной ASP-код не будет никак от этого зависеть, т.к. форма вызова остается унифицированной.
Приведенный пример достаточно прост. В нем отсутствуют, в частности, средства управления транзакциями и т.п. Однако даже описанным API (который разрабатывается достаточно быстро) можно решать вполне широкий круг задач ASP проектов.
