iri_iriДоброй всем ночи!!!

У меня следующая проблема:
как бы это проектирование применить на практике?
как бы начать думать объектно?
вопрос конечно совсем реторический, наверное, но может посоветуете что-то....

могу посоветовать закачать книгу "addison wesley - data access patterns - database interactions in object-oriented applications" - там очень простые примеры и довольно жизненные. Есть хорошая книга Фаулера "Архитектура корпоративные приложений", но она посложнее и серьёзнее будет, так что пока ограничься первой.

Далее все програмёшки бухгалтерского ширпотреба (то что громко назывется корпоративными приложениями) обычно строятся однообразно:

Есть сущности предметной области - контракт, товар, движение по складу, и т.д. - обычно они легко определяются. Любое действие заключается в следующем: взять несколько объектов из БД, обработать их, положить обратно в базу.

Объекты как я сказал довольно легко придумать - каждая сущность реального мира отображаешь в класс. Операция положить/взять из базы - особо пока не заморачивайся, считай что у тебя есть способ сохранить любой объект/взять из базы. Этим будет заниматься какой-нить класс типа ObjectMapper - все алгоритмы твоего приложения будут запрашивать объекты у этого класса и также запрашивать сохранить объект.

Вобщем думай логически и всё получится, хотя когда сделаешь скорее всего поймёшь что всё криво и надо бы подругому - но опыт набрать можно тока так ;)

PS Ещё полистай книгу GoF "Приёмы объектно-ориентированного проектирования. Паттерны проектирования" - хорошо учит использовать объекты с умом :) Гради Буч-а читать не стоит - занудно и длинно объясняет очевидные весчи. По-моему книга несколько устарела.

iri_iri ИнтеграторЭтим будет заниматься какой-нить класс типа ObjectMapper - все алгоритмы твоего приложения будут запрашивать объекты у этого класса и также запрашивать сохранить объект.


а можно в этом месте поподробнее..

Как раз на этом месте подробнее не надо :) Вопрос сохранения объектов в базу должен тебя волновать меньше всего на этапе проектирования !

Вообще открываешь книгу которую я процитировал выше и видишь перед собой ответы на многие твои вопросы : найти нужный тебе раздел легко - книга по сути является справочником по различным вопросам.

Садишься за бумагу и карандаш и русешь в понятном только для тебя виде схемки твоей программы: какие сущности что делаю и за что отвечают, потом все свои сущности делаешь объектами и получаешь объектную модель ;)

Отображение данных в базу в 2-х словах :

есть объект

class Device {
public:
int nID;
string strName;
string strType;
....
};


есть твой класс, отвечающий за отображение

class ObjectMapper {
public:
void saveDevice(Device& device);
void loadDevice(int nID, Device& device);
.....
};

делаешь
Device device;
....
theObjectMapper.saveObject(device);

Это в самом примитивном случае - на практике там много тонкостей с блокировками и т.д. и т.п.

Повторюсь - на это не заморачивайся пока - считай что такой класс у тебя есть. В Жабе например вообще такая отображалка есть стандартная и имеет звучное название JDO.

NotGonnaGetUs Интегратор В Жабе например вообще такая отображалка есть стандартная и имеет звучное название JDO.

В java есть более звучная штука: hibernate(.org). С её использованием, останется думать только о реализации бизнес-процессов.


Вполне возможно - я не спец по жабе, так знаком немного ;)


Писать самому ObjectMapping - это откровенный маразм, если приложение действительно не является очень простым. Хотя всё зависит от того, какой смысл вложить в это понятие...
В книжке "Hibernate in action" - отлично написано о проблемах возникающих при попытках самостоятельного написания полноценных ORM систем.

Краем уха слышал, что вроде бы была попытка написать клона hibernate не то для С++, ни то для .NET.

А вот тут я поспорю. Во первых прежде чем пользоваться коммерческими продуктаминеплохо бы разобраться в принципах функционирования и изобрести велосипед. Браться за большие проекты сразу не имея опыта - тупиковое решение, так что подразумеваю что проект не большой. Во вторых верить в чудесное средсьво которое спасёт всех и вся в виде идеального JbjectMapper-a по меньшей мере наивно. Если начнёшь писать свой маппер то сразу поймёшь что такого решения нет и быть не может - рееляционная структура и объектная суть принципиально разные вещи и если думаешь об эффективности то сразу возникают серьёзные проблемы. Простой пример - в реляционном хранилище лучший вариант - использование запросов, которые могут быть эффективно оптимизированны РСУБД, а в объектном мире мы имеем перебор объектов - движение по иерархии. Так что чудес не бывает... За всё приходится платить в том числе и за универсальность.