Допустим мы пишем программу для работы с БД, например это система учета клиентов, стоит ли дублировать классы сущностей, то есть классы, которые отражают предметную область? Я много раз видел нечто подобное:

class MainClass
{

ArrayList Clients
void GetConnection(){}
void AddClient(Client x){}

}

class Client
{
string Name
string Manager
.....
}


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

Kachalov, а где об этом можно прочитать, можете что-то посоветовать - статью или книгу


aston,
"Неправильное понимание подобной архитектуры.
Архитектура предполагает, что в коллекцию ложатся не сами объекты целиком, а ссылки (REFS) на них."
К Вам та же просьба )

Petro123MLans,
если писать клиент-сервер без ОРМ, используя DAL, то классы на клиенте вообще не нужны.
Я имею ввиду классы бизнес-сущностей.
РСУБД - DAL(ADO\...) - DBAware(Grid\...)

То есть это нормальная ситуация, когда нет классов бизнес сущностей, а просто организованный набор гридов и формочек, а вся логика прописана в хранимых процедурах например?

А как лучше тот же конекшн сделать?
один на все приложение или для каждого грида - свой конекшн, датасет, дата адаптер и т.д.