Как проектировать ООП-структуру приложения? , исходя из идеологии ADO.NET

[rockbear]

Исходя из идеологии АДО.НЕТ данные должны загружаться на клиентскую машину, обрабатываться, а затем отправляться на сервер. Таким образом постоянное подключение не является обязательным для работы.
разберем для примера задачу "Учет книг в библиотеке"

имеем такие классы

Цитата

класс книга
(
поле название
поле дата прихода
поле дата ухода

)

класс читатель
(
поле фио
поле есть ли задолженность перед библиотекой
)


класс библиотека
(

метод заполнить коллекцию читателей
метод заполнить коллекцию книг

метод добавить/удалить/редактировать книгу
метод дать/забрать книгу пользователю
метод добавить/удалить/редактировать пользователя


коллекция читателей
коллекция книг
коллекция операций

метод загрузить коллекцию книг/пользователей в БД
)

Чтобы все было "канонично" при загрузке приложения выбираем всю информацию селектом в датасет, потом из датасета формируем коллекции пользователей, книг и операций и можем отключаться. Коллекции это отображение нашей базы в объектах нашей программы, то есть если есть таблица "пользователи" должна быть также соответствующая коллекция. После того, как мы поиграемся с этими коллекциями, мы подключаемся к БД и "заливаем" всю информацию обратно. Правильно? Канонично?


Но вот что делать если размер БД гигабайт .. этак...50? И все это копируется в соотствующие коллекции, вы представляете сколько памяти потребуется для работы такого приложения?


не лучше ли не выделываться с "сущностями" и просто сделать один класс:

Цитата

класс библиотека
(
метод добавить/удалить/редактировать пользователя
метод добавить/удалить/редактировать книгу
метод добавить/удалить/редактировать операцию (датьзабрать книгу у пользователя)

метод выбрать книгу(критерий)
метод выбрать пользователя (критерий)
)

таким образом у нас объектная модель отображается только в БД, структура самого приложения является только интерфейсом к базе.


может я "неправильно" думаю, просветите )

[Otello]

Цитата

Но вот что делать если размер БД гигабайт .. этак...50?

Может подгружать данные по мере необходимости?

Обычно так и делаю, подгружаю необходимые пользователю данные на клиентскую машину/либо в переменную сессии, если клиент web. По мере надобности подгружаю остальную часть данных. Грузить все ХХХ гигабайт не нужно, потому что пользователь не будет использовать сразу все данные.

[kolobok0]

Цитата rockbear @ 25.08.09, 12:25

.. И все это копируется в соотствующие коллекции, вы представляете сколько памяти потребуется для работы такого приложения?...

Не совсем понятно причём тут ОО? ОО начинается от ЗАКАЗЧИКА. То, что Вы написали классы - это Ваше виденье проблемы не больше. Тут уже простите - говорить об ОО уже поздно

По поводу клиент-серверных технологий и методов нахождения сущностей.
1) Нужно внимательно слушать заказчика. Те сущиствительные которые он применяет в описании технологии - есть (обычно) сущности (как правило они вытекают в классы). Те глаголы которые заказчик употребляет (как правило) - это методы классов.
2) После тщательной (несколько итераций) отшлифовки бизнес структуры, надо на неё глянуть с точки зрения удобства юзанья программером - т.е. накрытия всего требуемуего функционала программы. Так структура классов дополняется групповыми операциями(и возможно вспомогательными классами) которые собственно не всегда видны пользователю.
3) Далее собственно надо на весь колхоз взглянуть с точки зрения клиент-сервера. Обычно вертикаль нечто похожая на: графика-бизнес-интерфейс комуникаций-сервак-бд. На срезах сервак и интерфейс к нему - вот именно там и нужно сделать волшебным образом оптимизацию. Почему волшебным? потому как сильно зависит от задачи и от вашей найденной структуры классов.
4) Далее БД затачивается на оптимизацию по самим операциям и их частоте юзанья: вставки-удаление-выборка-изменение.


удачи Вам
(круглый)
ЗЫ
Можно конечно же начать сразу с классов, и спрашивать на форумах куда поставить подпорочки. Но со временем выращенный Ваш монстрик ёб...ца в самый неподходящий момент. И тут же родится мысль - перепишем ка всё с нуля.... И будет повторное наступление на грабли и итерационно набивание шишки на одном и том же месте. Думаю Вам это знакомо. Но это другая история.

[Raistlin]

Цитата rockbear @ 25.08.09, 12:25

не лучше ли не выделываться с "сущностями" и просто сделать один класс:

Добавлю, что оба архитектурных решения уже давно изобретены
http://martinfowler.com/eaaCatalog/domainModel.html
http://martinfowler.com/eaaCatalog/transactionScript.html