s> Автор: sandreynik
12345678> В том то и дело, что наследование кода в отрыве
12345678> от наследования структур данных, с которым ему
12345678> работать, - это полумера. За соответствием одного
12345678> другому надо следить глазками.
s> Нормальная практика когда объект имеет метод или
s> интерфейс Persistance. Вот он пусть и следит.
12345678> вообще-то за этим должен следить компилятор.
s> Компилятор следит за тем что декларировано в синтаксисе языка.
s> Значит просто надо написать другой компилятор для другого языка.

То, за чем должен следить компилятор, а что проверяется в момент выполнения,
зависит от степени типизации языка программирования: статическая или
динамическая.

Аналогичо, нормальность практики размежевания полей и методов доступа
варируется от языка к языку.

12345678> Зачем клиенту запрашивать сами сами объекты с сервера,
12345678> если он может работать с ними через свойства и методы?
12345678> Если же каждому серверному объекту сопоставлен клиентский
12345678> - то их личное дело, какими данными и через что они
12345678> обмениваются. Можно и через самый примитивный SQL,
12345678> если серверные объекты прикручены триггерами к данным.

Соверженно верно. Ввиду слабой совместимости моделей данных нереально
полагаться на то, что какому-нибудь чудо-вендору удасться зашить ООП в
реализацию SQL на сервере. Современые "объектные расширения" на серверных
платформах - это убожества по сравнение с тем, что предоставляют полноценные
системы программирования для клиента.

Практичнее иметь чёткое разделение: SQL - на сервере, "настоящие" объекты -
на клиенте. Правда, достаточность примитивного SQL для клиента спорна.
Использование "плоских" предложений ввиде строк весьма утомительна для
программирования.

Пример удачной интеграции - CommonSQL, разработанный фирмой Xanalys (ныне
LispWorks) около десяти лет назад, см., например:

http://www.lispworks.com/documentation/lw50/LWUG/html/lwuser-268.htm
(Имеются и реализации в открытом коде.)

Это расширение Коммон Лиспа как библиотечными фукнциями, так и макросами
(осмелюсь утверждать, что выразительные возможности и удобство
макропрограммирования на Лиспе велики, как ни в каком другом языке).
Объекто-ориентированный интерфейс включает:

- определения классов, экземпляры которых отображаются в записи РБД
(наиболее просто реалзиуется подход "2. Практично. Один КОНКРЕТНЫЙ класс =
одна таблица").

- операции выборки и сохранения.

Пример:

(def-view-class employee (standard-db-object)
((employee-number :db-kind :key
:column empno
:type integer)
(employee-name :db-kind :base
:column ename
:type (string 20)
:accessor employee-name)
(employee-department :db-kind :base
:column deptno
:type integer
:accessor employee-department)
(employee-job :db-kind :base
:column job
:type (string 9))
(employee-manager :db-kind :base
:column mgr
:type integer)
(employee-location :db-kind :join
:db-info (:join-class department
:retrieval :deferred
:set nil
:home-key employee-department
:foreign-key department-number
:target-slot department-loc)
:accessor employee-location))
(:base-table emp))


Posted via ActualForum NNTP Server 1.4

>> автор
>> Практичнее иметь чёткое разделение: SQL - на сервере, "настоящие"
>> объекты - на клиенте.
> А если клиент веб-страница или что-то еще более примитивное - где
> тогда будут объекты - на сервере приложений?

Разумеется, на сервере приложений. Объекты в браузерах довольно зачаточные.

> А если клиентов с объектами несколько разных, кто будет
> отвечать за соответствие заложенной в них логики?

Отчасти - сервер БД (общие ограничения целостности), отчасти - клиент или
сервер приложений.

> Вот в том-то и дело, что хотелось бы иметь реализацию всей логики,
> обрабатывающей вводимые данные на сервере, и желательно сервере БД
> (так и секурнее и централизованнее и быстрее и проще кажется). А на
> деле получается - кусочек логики в БД, кусочек в серверном
> приложении, кусочек в клиентских - арррр(((.

Это достойный идеал, но на практике всегда будет иначе. Конечно, в
трехзвенке следует сокращать роль оконечных Web-клиентов.

ИMХО
1) Возможности программирования на браузерах слишком преувеличены, если не
сказать "раздуты", их производителями. Конечно, браузер может поддерживать
пародию на объекты, обычно с помощью плагинов, но тогда чем он лучше
специализированного клиента?

2) Зачастую HTTP протокол является существенным ограничителем по сравнению с
"родными" клиентскими протоколами СУБД.


Posted via ActualForum NNTP Server 1.4