Здравствуйте, DemAS, Вы писали:

DAS> Как я понимаю, это общепринятая практика ? По моему, если я не ошибаюсь, именно это называется mapping. Это так ?
Почти.

DAS> Где можно почитать про способы, подходы, рекомендации реализации этой идеи.
Примеры и исходники можно взять здесь:
Hibernate или NHibernate
или
.NET Data Access Objects

Почитать можно здесь.

Здравствуйте, iZEN, Вы писали:

ZEN>Здравствуйте, DemAS, Вы писали:

DAS>> Есть база данных. В ней есть таблицы. Талицы справочники представляют собой какие-то сущности: например — поставщики, товары, адреса....
DAS>> Есть программа, которая работает с базой данных. По хорошему, как я понимаю, все эти сущности из БД должны каким-то образом отображаться на классы в программе. То есть у меня в программе должны присутствовать классы Поставщик, Товар, Адрес. Более того, как я понимаю, все изменения в БД должны происходит через методы этих объектов. То есть продажа товара поставщику должна происходить примерно так: Поставщик.Sale(Товар), а уже реализация этого метода должна вызывать измениея в БД.
DAS>> Как я понимаю, это общепринятая практика ? По моему, если я не ошибаюсь, именно это называется mapping. Это так ?

ZEN>Да.

А делают, что то типа такого?: Сущности — только класс со свойствами, и еще один слой — слой логики где происходит манипуляция с этими сущностями. Или этот подход не верен?

типа:

class Person
{
public int ID;
public string FullName;
}

class PersonBusinesLogic
{
public bool CheckCredit(Person p)
{
///
}
}

DAS>> Где можно почитать про способы, подходы, рекомендации реализации этой идеи.

ZEN>Так Java2 Enterprise Edition, в частности технология EJB (CMP, BMP, etc.), именно это имеет в своей основе.
ZEN>http://java.sun.com/products/ejb/docs.html

Здравствуйте, lextasy, Вы писали:

L>Предлагаю дальнейшее развитие идеи:

L>1) Проектируем интерфейсы всех сущностей домена. Получаем их определения на языке IDL.
L>2) С каждой сущностью связываем OID
L>3) По исходному IDL генерируем IDL для удаленного доступа, следующим образом:

То что ты предлагаешь называется DCOM.
Это я к тому что оно как бы уже и так есть.
Надо просто зарегистрировать твою classlib как out-of-process-remote.

То что есть — точно. А вот детали уже не упомню.

Здравствуйте, <Аноним>, Вы писали:
А>А делают, что то типа такого?: Сущности — только класс со свойствами, и еще один слой — слой логики где происходит манипуляция с этими сущностями. Или этот подход не верен?
А, пардон, зачем? Чтобы побольше было мест, где надо изменения вносить при выявлении новых требований?

Здравствуйте, c-smile, Вы писали:

CS>Здравствуйте, lextasy, Вы писали:

L>>Предлагаю дальнейшее развитие идеи:

L>>1) Проектируем интерфейсы всех сущностей домена. Получаем их определения на языке IDL.
L>>2) С каждой сущностью связываем OID
L>>3) По исходному IDL генерируем IDL для удаленного доступа, следующим образом:

CS>То что ты предлагаешь называется DCOM.
CS>Это я к тому что оно как бы уже и так есть.
CS>Надо просто зарегистрировать твою classlib как out-of-process-remote.

CS>То что есть — точно. А вот детали уже не упомню.

Если использовать DCOM как есть, т.е. "просто зарегистрировать твою classlib как out-of-process-remote", то получим такие траблы, из-за которых, собственно, DCOM и не прижился (помимо всего прочего, конечно):
1) Клиенту придется на каждый объект БД инстанцировать proxy-объект, а серверу — соответствующий stub. Это не только на порядок уменьшит отзывчивость сервера, но и сильно ударит по ресурсам обоих машин.
2) Будут огромные тормозняки из-за того, что интерфейсы, спроектированные для непосредственного (in-process) доступа, непригодны для удаленного доступа. Для удаленного доступа нужна гранулярность запросов побольше, а частота — поменьше.
3) Про stateless — сервер можно будет забыть, иначе у клиентов начнутся проблемы типа E_DISCONNECT при попытке доступа к уже удаленным на сервере объектам. Да и CoDisconnectObject() на каждый пук вызывать просто по-человечески жаба давит.
4) Управление транзакциями невозможно будет полностью инкапсулировать на сервере — с учетом предыдущих проблем это значит полный каюк, если клиентов планируется много.

Хотя предложенная реализация базируется на DCOM, она не сводится просто к использованию DCOM. Это именно ШЛЮЗ, предоставляющий ФИКСИРОВАННОЕ количество интерфейсов, ОТНЮДЬ НЕ ТОЖДЕСТВЕННЫХ тем интерфейсам, которые определениы в исходной библиотеке типов, используемой сервером.
Просто это, так скажем, более жестко типизированный шлюз, т.е. использует более детерминированный протокол и соответственно приводит к меньшему количеству ошибок, обусловленных нарушением протокола. Думаю, это важно, т.к. в процессе разработки системы протокол шлюза эволюционирует, и хотелось бы чтобы при этом компилятор помогал выявлять код, требующий обновления.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, <Аноним>, Вы писали:
А>>А делают, что то типа такого?: Сущности — только класс со свойствами, и еще один слой — слой логики где происходит манипуляция с этими сущностями. Или этот подход не верен?
S>А, пардон, зачем? Чтобы побольше было мест, где надо изменения вносить при выявлении новых требований?

А если веб сервисы? Возвращать прямо BusinessComponent?

Здравствуйте, <Аноним>, Вы писали:
А>А если веб сервисы? Возвращать прямо BusinessComponent?
Ну... зависит от задачи

Здравствуйте, c-smile, Вы писали:

Извиняюсь, но вынужден поднять этот давний вопрос.

CS>Я бы порекомендовал тебе сделать две функции типа:

CS>collection read(id request, collection parameters)
CS>collection write(id request, collection parameters)

CS>и спрятать за ними весь код физической работы с базой данных.
CS>Т.е. если тебе придется перейти на другую архитектуру БД или в сеть тебе не придется глобально все переделывать.
CS>Заодно такой подход дисциплинирует от размазывания БД по всему приложению.

Что в данном случае представляет собой collection parameters? Это коллекция (ArrayList) неких объектов, в которых кроме самого значения параметра долна храниться информация о его типе?

То есть у меня есть такой код.

     ArrayList Write(string query, ArrayList parameters)
        {
            FbConnection connection = dbManager.GetConnection();
            connection.Open();
            FbCommand command = new FbCommand(query, connection);

                        // from here
            command.Parameters.Add("@parentid", FbDbType.Integer).Value = task.parent_id;
            command.Parameters.Add("@name", FbDbType.VarChar).Value = task.name;
            command.Parameters.Add("@description", FbDbType.VarChar).Value = task.description;
            command.Parameters.Add("@category", FbDbType.Integer).Value = 4;
                        // to here
            
            command.ExecuteNonQuery();            
            connection.Close();
        }

Какова долдна быть структура parametrs, чтобы я смог динамически извлечь эти параметры и заменить код между комментариями?