Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / WinForms, .Net Framework Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Пользовательские коллекции  [new]
hey
Guest
Во многих классах требуется иметь коллекцию объектов.
Нужно что-бы клиентский код мог искать в ней определенные объекты (по образу функции Find() в List<>) по заданному ключу (например найти объкт по строковому имени и пр.).
Также класс, владеющий этой коллекцией должен иметь возможность контролировать операции добавления/удаления элементов в коллекцию (например при вызове у коллекции функции AddNew() занести эти данные в базу данных).

У BindingList есть почти все эти возможности за исключением функции Find().

Неужели надо создавать пользовательский класс для каждой коллекции ? (как например DataRowCollection в DataTable и пр.)
5 дек 07, 10:22    [5004372]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
МСУ
Member [заблокирован]

Откуда: http://codearticles.ru
Сообщений: 31089
Хабар
5 дек 07, 10:27    [5004415]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey
Также класс, владеющий этой коллекцией должен иметь возможность контролировать операции добавления/удаления элементов в коллекцию (например при вызове у коллекции функции AddNew() занести эти данные в базу данных).

Не должен. Подумайте над архитектурой и почитайте про SRP.
5 дек 07, 10:45    [5004569]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
МСУ

Хабар

и ? Класс BindingList не обладает методом Find().

Нахлобуч

Не должен. Подумайте над архитектурой и почитайте про SRP.

точно, не должен.

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

У BindingList кстати еще такой недостаток появляется, что функция производящая валидацию добавляемого элемента окажется в классе-владельце коллекции
5 дек 07, 15:36    [5007441]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey
Но все-таки непонятно, что делать-то теперь. Плодить классы-коллекции ? Их много получиться :(

Ну и что? Если во втором фреймворке, то вообще три строки кода.
hey

При том, что их действия в основном очень похожи - при добавлении элемента провести валидацию по некому алгоритму, занести в БД. При удалении - стереть из БД.

Да ну не должны они этого делать. Коллекция -- это просто коллекция, ей не должно быть дела до базы данных. Почитайте еще и про ORM.
5 дек 07, 15:41    [5007483]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Нахлобуч

Ну и что? Если во втором фреймворке, то вообще три строки кода.

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

Нахлобуч

Да ну не должны они этого делать. Коллекция -- это просто коллекция, ей не должно быть дела до базы данных

хорошо, не сама сохраняет, а вызывает метод Commit() своего элемента :) Суть остается - проверить элемент на допустимость добавления в коллекцию, вызвать Commit().
5 дек 07, 16:14    [5007787]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey

Ох.. И в третий раз повторяю -- ничего из вышеперечисленного коллекция делать не должна. Надо так:

public class DocumentChapterCollection : CollectionBase<DocumentChapter>
{
}

public class Document
{
	private DocumentChapterCollection chapters = new DocumentChapterCollection();
	
	public void AddChapter(DocumentChapter chapter)
	{
		if(chapter.Name == string.Empty)
			throw new BusinessRuleViolationException("DocumentChapter.Name");
			
		chapter.Document = this;
		chapters.Add(chapter);
	}
}

public class DocumentManager
{
	public void SaveDocument(Document document)
	{
		// Сохранение документа в БД
	}
}
5 дек 07, 16:21    [5007847]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Нахлобуч

Ох.. И в третий раз повторяю -- ничего из вышеперечисленного коллекция делать не должна. Надо так:

т.е. вы все аттрибуты коллекции (Add(), Delete(), Find() итп) просто вынесли в интерфейс класса-владельца коллекции ?
А как-же быть, если пользователь захочет пройти по коллекции foreach'ем ? Или получить значение по индексу ?
Или если коллекция может использоваться в нескольких разных классах ?

Разве не лучше все действия по манипулированию набором элементов сосредоточить в одном месте ?
5 дек 07, 16:40    [5007987]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey
т.е. вы все аттрибуты коллекции (Add(), Delete(), Find() итп) просто вынесли в интерфейс класса-владельца коллекции ?
А как-же быть, если пользователь захочет пройти по коллекции foreach'ем ? Или получить значение по индексу ?
Или если коллекция может использоваться в нескольких разных классах ?


Разве не лучше все действия по манипулированию набором элементов сосредоточить в одном месте ?[/quot]
5 дек 07, 16:46    [5008023]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
То сообщение как-то внезапно отправилось.
hey

т.е. вы все аттрибуты коллекции (Add(), Delete(), Find() итп) просто вынесли в интерфейс класса-владельца коллекции ?
А как-же быть, если пользователь захочет пройти по коллекции foreach'ем ? Или получить значение по индексу ?
Или если коллекция может использоваться в нескольких разных классах ?

По-моему, достаточно ясно видно, что Document.AddChapter() как раз таки и осуществляет всю так вам необходимую валидацию -- именно для этого он и нужен. Остальные методы (эти самые Delete(), Find() и прочие) оставляйте на здоровье в классе-коллекции, там им самое место.
5 дек 07, 16:49    [5008046]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Нахлобуч

По-моему, достаточно ясно видно, что Document.AddChapter() как раз таки и осуществляет всю так вам необходимую валидацию -- именно для этого он и нужен. Остальные методы (эти самые Delete(), Find() и прочие) оставляйте на здоровье в классе-коллекции, там им самое место.

а, т.е. поле с классом-коллекцией является public, у вас просто там это не показано.

Конечно извиняюсь за назойливость, но все-таки непонятно, чем метод Add() заслужил выделения в интерфейс владельца. Во-первых эта функция хорошо ложиться именно в интерфейс коллекции, а не владельца, во-вторых, коллекция может быть в нескольких разных классах одновременно, в результате чего получиться несколько одинаковых функций валидации в разных классах ...
5 дек 07, 17:15    [5008297]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Gasanov2003
Member

Откуда:
Сообщений: 209
МСУ
Хабар


что означает слово "Хабар"? (чисто любопытство)
5 дек 07, 17:22    [5008362]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey

а, т.е. поле с классом-коллекцией является public, у вас просто там это не показано.

Нет, оно именно private. Наружу должно торчать свойство.
hey

Конечно извиняюсь за назойливость, но все-таки непонятно, чем метод Add() заслужил выделения в интерфейс владельца. Во-первых эта функция хорошо ложиться именно в интерфейс коллекции, а не владельца,

Заслужил выделения тем, что в методе AddChapter выполняется та самая валидация, на которую вы так напираете.

В интерфейс коллекции она не ложится хотя бы по той причине, что в коллекции могут находится, например, не до конца инициализированные объекты DocumentChapter. Добавить такие главы в Document с помощью AddChapter нельзя, а в DocumentChapterCollection они могут прекрасно себя чувствовать.

Коллекция -- это просто коллекция. Следуйте принципу наименьшего удивления: я должен иметь возможность добавить в такую коллекцию любой объект класса DocumentChapter.
hey

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

А вынести валидацию в отдельный класс?
5 дек 07, 17:23    [5008377]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
tAZAR
Member

Откуда: Москва
Сообщений: 2051
Gasanov2003

что означает слово "Хабар"? (чисто любопытство)

"Барахло" в смысле просто некой ценности, а не качества. То, что можно найти и взять.
Почитайте Стругацких, "Пикник на обочине".
З.Ы. С интересом читаю тему :-)

ИМХО, метод добавления стоит выделять чтобы не переписывать стандартный метод Add коллекции. Менеджер документов именно этим заниматься и должен (контроль, добавление, удаление и т.д.).
5 дек 07, 17:33    [5008451]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Нахлобуч

Нет, оно именно private. Наружу должно торчать свойство.

да, я и имел ввиду проперти, то, что chapters было private я видел :)

Нахлобуч

В интерфейс коллекции она не ложится хотя бы по той причине, что в коллекции могут находится, например, не до конца инициализированные объекты DocumentChapter. Добавить такие главы в Document с помощью AddChapter нельзя, а в DocumentChapterCollection они могут прекрасно себя чувствовать.

а что значит "не до конца инициализированные" ? Известно, что конструктор класса создает "готовый" объект (удовлетворяющий всем инвариантам класса). Т.е. если объект построен правильно, почему его нельзя добавить в Document?
А вот уже при добавлении должна проводиться валидация уровня коллекции, например что-бы chapter имел уникальный для коллекции номер главы и т.п.

Нахлобуч

Коллекция -- это просто коллекция. Следуйте принципу наименьшего удивления: я должен иметь возможность добавить в такую коллекцию любой объект класса DocumentChapter.

т.е. по вашему можно добавить туда null. Или несколько идентичных объектов. Честно говоря не понимаю, чем это так лучше.
Раз уж выделили набор chapters в отдельный класс DocumentChapterCollection, то непонятно, почему допускаем очевидно логически неверный вариант наличия там одинаковых (или вообще null) объектов

Нахлобуч

А вынести валидацию в отдельный класс?

раз вы так любите разные принципы, то должны знать, что это вступает в противоречие с тем принципом, что дополнительные сущности нужно вводить только по необходимости. Собственно, именно он и заставил меня сомневаться, что много классов с похожей функциональностью это хорошо :)
5 дек 07, 17:52    [5008621]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
tAZAR

ИМХО, метод добавления стоит выделять чтобы не переписывать стандартный метод Add коллекции

а зачем его переписывать ?
5 дек 07, 17:56    [5008650]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey
а что значит "не до конца инициализированные" ? Известно, что конструктор класса создает "готовый" объект (удовлетворяющий всем инвариантам класса).

Откуда такое известно? Конструктор, в общем случае, создает объект, полностью инициализированный с точки зрения CLR и не более.
hey

Т.е. если объект построен правильно, почему его нельзя добавить в Document?

Что такое "правильно"?
hey

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

Ну вот предположим:
public DocumentChapterCollection PrepareChapters()
{
	DocumentChapterCollection chapters = new DocumentChapterCollection();		

	// Просто пример. В реальной жизни главы может добавлять пользователь, так что
	// заранее может быть неизвестно их число.
	chapters.Add(new DocumentChapter());
	chapters.Add(new DocumentChapter());
	
	foreach(DocumentChapter chapter in chapters)
		chapter.Name = string.Format("Глава {0} из {1}", chapters.IndexOf(chapter), chapters.Count);
		
	return chapters;
}

Как бы вы то же самое сделали с черезчур умной коллекцией?

hey

т.е. по вашему можно добавить туда null. Или несколько идентичных объектов. Честно говоря не понимаю, чем это так лучше.

Несколько идентичных объектов -- сколько угодно. null -- нет, и эта проверка легко выносится в базовый класс. null не допускаем просто потому, что нет в этом смысла вообще.
hey

Раз уж выделили набор chapters в отдельный класс DocumentChapterCollection, то непонятно, почему допускаем очевидно логически неверный вариант наличия там одинаковых (или вообще null) объектов

DocumentChapterCollection -- это семантический аналог List<DocumentChapter>, то есть просто контейнер для объектов типа DocumentChapter. Все. Не больше.
hey

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

И где тут противоречие? Потребовалось избежать дублирования кода (вуаля! новый принцип :) ) -- мы и вынесли общий функционал в отдельный класс.
5 дек 07, 18:08    [5008761]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Нахлобуч

Откуда такое известно? Конструктор, в общем случае, создает объект, полностью инициализированный с точки зрения CLR и не более.

хм, позвольте здесь серьезно не согласиться. Конструктор отвечает за то, чтобы объект родился "правильным". И сформулировано это еще Бертраном Мейером. Т.е. например если chapter имеет инвариант "номер главы всегда больше нуля", то конструктор обязан это обеспечить.

Нахлобуч

Что такое "правильно"?

выполняются все инварианты класса (т.е. условия, которые справедливы для всего класса в любой момент времени до и после вызова любого из public методов). Инвариант может быть нарушен только при вызове private метода и обязан быть потом возращен на место.

Нахлобуч

Как бы вы то же самое сделали с черезчур умной коллекцией?

Ну во-первых вы как раз и создали chapter без порядкового номера, что скорее всего неправильно. Во-вторых я не совсем понял пример - если теперь добавить еще один chapter, то как быть с именами предыдущих (они-же перестали быть актуальными) ?

Нахлобуч

Несколько идентичных объектов -- сколько угодно. null -- нет, и эта проверка легко выносится в базовый класс. null не допускаем просто потому, что нет в этом смысла вообще.

ну и зачем нам несколько идентичных объектов ?

Нахлобуч

DocumentChapterCollection -- это семантический аналог List<DocumentChapter>, то есть просто контейнер для объектов типа DocumentChapter. Все. Не больше.

хм, я кстати пропустил из предыдущего поста одну важную вешь - если DocumentChapterCollection торчит наружу (и является лишь оберткой вокруг List<DocumentChapter>), то что мешает клиенту вызвать метод Add() прямо из коллекции в обход валидации в методе класса-владельца ?
Кроме того, будут доступны методы Delete, Find и пр. Значит объект можно будет просто удалить из коллекции (и как я потом узнаю, что это изменение надо проводить в БД), а для Find придется писать метод-предикат в клиентском коде.
Короче все проблемы, из-за которых я и открыл топик :)

Нахлобуч

И где тут противоречие?

как где :) прячем валидацию элемента в DocumentChapterCollection и никаких доп. сущностей и дублирования кода :)
5 дек 07, 18:46    [5008993]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Sa
Member

Откуда: Ekaterinburg
Сообщений: 4019

hey

хм, позвольте здесь серьезно не согласиться. Конструктор отвечает за то, чтобы объект родился "правильным". И сформулировано это еще Бертраном Мейером. Т.е. например если chapter имеет инвариант "номер главы всегда больше нуля", то конструктор обязан это обеспечить.

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

Вообще достаточно часто встречаются следующая конструкция:
1) объект создается
2) фиксируется то, что объект не инициализирован
3) объект инициализируется
4) фиксируется то, что объект инициализирован


P.S. а я вообще по теме ?

uid = Sa

Posted via ActualForum NNTP Server 1.4

5 дек 07, 19:59    [5009186]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Sa
Member

Откуда: Ekaterinburg
Сообщений: 4019

2 hey
то чем вы сейчас занимаетесь, это определение какие обязанности должен нести тот или иной класс, думаю будет полезно почитать GRASP - шаблоны для распределения обязанностей Крэйга Лармана (Craig Larman), описанные в книге: "Применение UML и шаблонов проектирования"

uid = Sa

Posted via ActualForum NNTP Server 1.4

5 дек 07, 20:01    [5009189]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Бодрый
Guest
Gasanov2003
что означает слово "Хабар"?


Хабар в тюркских языках означает "новость"
5 дек 07, 20:47    [5009276]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
hey
Guest
Sa

Что то я не помню такого у Мейера



Бертран Мейер

Preconditions and postconditions describe the properties of individual routines. There is
also a need for expressing global properties of the instances of a class, which must be
preserved by all routines. Such properties will make up the class invariant, capturing the
deeper semantic properties and integrity constraints characterizing a class.

...

A class invariant is such an assertion, expressing general consistency constraints that
apply to every class instance as a whole; this is different from preconditions and
postconditions, which characterize individual routines.

...


The role of creation procedures

The discussion of invariants yields a better understanding of the notion of creation procedure.
A class invariant expresses the set of properties that objects (instances of the class)
must satisfy in what has been called the stable moments of their lifetime. In particular,
these properties must hold upon instance creation.
The standard object allocation mechanism initializes fields to the default values of the
corresponding attribute types; these values may or may not satisfy the invariant. If not, a
specific creation procedure is required; it should set the values of the attributes so as to
satisfy the invariant. So creation may be seen as the operation that ensures that all instances
of a class start their lives in a correct mode — one in which the invariant is satisfied.
The first presentation of creation procedures introduced them as a way to answer a
more mundane (and obvious) question: how do I override the default initialization rules if
they do not suit me for a particular class, or if I want to provide my clients with more than
one initialization mechanism? But with the introduction of invariants and the theoretical
discussion summarized by rule C1, we also see the more profound role of creation
procedures: they are here to make sure that any instance of the class, when it starts its life,
already satisfies the fundamental rules of its caste — the class invariant.



Sa

Да и не всегда возможно обеспечить это. Представьте ситуацию когда необходимые данные нужно "взять" из БД. ну не в конструкторе же это делать?!?

если данные, необходимые для обеспечения инвариантов нужно брать из БД, то почему-бы собственно не сделать это в конструкторе ?

Sa

Вообще достаточно часто встречаются следующая конструкция:
1) объект создается
2) фиксируется то, что объект не инициализирован
3) объект инициализируется
4) фиксируется то, что объект инициализирован

почему нельзя инициализировать сразу в конструкторе ?

Sa

то чем вы сейчас занимаетесь, это определение какие обязанности должен нести тот или иной класс, думаю будет полезно почитать GRASP - шаблоны для распределения обязанностей Крэйга Лармана (Craig Larman), описанные в книге: "Применение UML и шаблонов проектирования"

читал, и не только их :) Потому и возникают такие вопросы ...
5 дек 07, 20:48    [5009282]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Sa
Member

Откуда: Ekaterinburg
Сообщений: 4019

Bertrand Meyer


этот текст мне знаком. но Майер здесь не говорит о том, что та самая процедура создания (creation procedures) о которой идет речь является именно КОНСТРУКТОРОМ. заметьте он ни слова в этом тексте не говорит про конструктор. ПРи этом применяет слово КОНСТРУТКТОР достаточно четко в других местах .
Почему подобной процедурой создания (creation procedure), гарантирующей, что все экземпляры класса имеют нужный статус и инвариант выполняется не может выступать метод Initialize(bla-bla-bla).
hey

если данные, необходимые для обеспечения инвариантов нужно брать из БД, то почему-бы собственно не сделать это в конструкторе ?

а обработку исключений где делать? а если при этом потребуется скинуть сообщение об ошибке в лог файл. при помощи объекта логгирования, который еще не создан. ИМХО плохой подход в конструкторе прописывать подобные вещи.

hey

почему нельзя инициализировать сразу в конструкторе ?

потому что это неудобно. Порой перегруженных контструкторов может быть n-ое очень большое количество, лично меня такие классы сильно разражают. ИМХО в этом случае красивее и нагляднее использовать свойства класса, для некоторой доинициализации объекта.

Самостоятельное задание:
1) Создайте UserControl
2) Сделайте конструктор а-ля creation procedure с передачей всех необходимы параметров.
3) Попробуйте использовать данный UserControl в дизайн тайм на какой либо форме.


uid = Sa

Posted via ActualForum NNTP Server 1.4

5 дек 07, 21:42    [5009397]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
Нахлобуч
Member

Откуда: https://hglabhq.com
Сообщений: 3939
hey

хм, позвольте здесь серьезно не согласиться. Конструктор отвечает за то, чтобы объект родился "правильным". И сформулировано это еще Бертраном Мейером. Т.е. например если chapter имеет инвариант "номер главы всегда больше нуля", то конструктор обязан это обеспечить.

выполняются все инварианты класса (т.е. условия, которые справедливы для всего класса в любой момент времени до и после вызова любого из public методов). Инвариант может быть нарушен только при вызове private метода и обязан быть потом возращен на место.

Как тут уже сказали, это не всегда возможно.
hey

Ну во-первых вы как раз и создали chapter без порядкового номера, что скорее всего неправильно.

Неправильно с какой точки зрения?
hey

Во-вторых я не совсем понял пример - если теперь добавить еще один chapter, то как быть с именами предыдущих (они-же перестали быть актуальными) ?

Пример был вот о чем: пользователь (допустим, в WinForms-приложении, это дела не меняет) создает Document, добавляя в него DocumentChapter'ы. Сколько их он там добавит -- неизвестно, следовательно, текст "Глава xx из yy" мы можем получить только после того, как все главы были добавлены. Как прикажете инициализировать объекты DocumentChapter в конструкторе?
hey

ну и зачем нам несколько идентичных объектов ?

Затем, что список (List) семантически такое допускает. Если б мы говорили про DocumentChapterSet -- тогда бесспорно, идентичных объектов там быть не должно (да и не может).

hey

хм, я кстати пропустил из предыдущего поста одну важную вешь - если DocumentChapterCollection торчит наружу (и является лишь оберткой вокруг List<DocumentChapter>), то что мешает клиенту вызвать метод Add() прямо из коллекции в обход валидации в методе класса-владельца ?

Правильно, никто не мешает. Точно так же как никто не мешает выполнить любое другое "деструктивное" действие с любым другим API. Есть, конечно, необходимость в некоей "защите от дурака", но там легко перегнуть палку.

К тому же, умный DocumentChapterCollection оказывается накрепко прибитым к Document и использовать его как-то иначе (как -- см. выше) уже не выйдет.
hey

Кроме того, будут доступны методы Delete, Find и пр. Значит объект можно будет просто удалить из коллекции (и как я потом узнаю, что это изменение надо проводить в БД),

Совершенно верно. По поводу отслеживания изменений -- все довольно просто, можете посмотреть как это сделано, например, в NHibernate.
hey

а для Find придется писать метод-предикат в клиентском коде.

А вы представляете, в таком случае, публичный интерфейс класса Document, если на каждый чих там будет отдельный метод?
6 дек 07, 11:24    [5010855]     Ответить | Цитировать Сообщить модератору
 Re: Пользовательские коллекции  [new]
D129
Member

Откуда:
Сообщений: 13918
автор
почему нельзя инициализировать сразу в конструкторе ?


Было, было такое! примерно так - в контсрукторе объекта "Телега" создаем инстанс драйвера, который в свою очередь открывает сокет, сокет коннектится к контроллеру, а потом запрашивается координата телеги, которой управляет контроллер (для того, чтобы вывести ее на форме). Ну и - контроллеров 35 штук, сделали асинхронный коннект, конструкторо проскакивает, но координаты не получает - сокеты еще не подсоединились.


Вот, пришлось запрос координаты делать позже.
6 дек 07, 11:33    [5010934]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / WinForms, .Net Framework Ответить