В Доменном Управляемом Дизайне, когда объект клонирует себя, кто добавляет его к его контейнеру?
Так что я мучился по этому поводу, и я понял это.
Вам не нужна другая кнопка или что-то еще.
Все, что вам нужно сделать, это выбрать «Владелец файлов», в инспекторе перетащить из его выхода textField (или как вы его назвали) в ваше фактическое текстовое поле (через то, что вы назвали его) Это будет в дополнение к все, что вы уже подключили.
и, конечно же, в дополнение к выходу Control (UIview изменен на UIControl через инспектора) для владельца файлов через backgroundtouched ... первое, что мы все попробовали
5 ответов
После прочтения проекта Domain Driven Design (Evans) может показаться, что с этим сценарием лучше всего справиться с помощью службы .
В DDD это часто зависит от домена. Здесь пример - и, следовательно, домен - кажется немного странным, но я бы выбрал метод SplitCell в Body .
Хотя мне не очень понятно, что расщепление клеток означает, и то, что должно вызвать это действие, я думаю, тело отвечает за расщепление своих клеток. Мне было бы удобнее использовать метод Regenerate или что-то в этом роде для Body , которое разбивает внутренние ячейки, вызывая метод Split для каждой из них.
Хорошо, этот пример определенно странный ...
Я бы подумал, что Body просто вызовет splitCell () для Cell. Тогда Тело может делать с новой Клеткой все, что хочет - добавлять к себе, потреблять, отбрасывать, что угодно. В любом случае Тело содержит Клетку.
Хорошо, другой подход - отправить в Тело событие, говорящее «Я расщепляюсь» или что-то еще. И тогда Body может забрать новую Cell - возможно, как полезную нагрузку этого события.
Если ваш внешний субъект не знает о теле, должен ли метод Split возвращать новый клон Cell? Собирается ли это каким-то образом использовать внешний субъект? Или может метод Split ничего не возвращать (Void) и просто отправлять сообщение телу, в котором он находится?
Using events on the Cell class seems like a natural solution, but it's trickier to implement in C#.
You'll need to hook up events when Cells come into scope, and you'll also need to unhook them when they go out of scope - otherwise you'll get memory leaks.
You also need to hook up events whenever a cell is re-associated with a Body, i.e. when cells are retrieved from a persistence store. Using a container to manage the relationships (possibly an ORM interceptor) could make this easier.
The simpler alternative is to hold a reference to the parent Body (cells only belong to a single Body, right?), and let the new Cell add itself to it's Body.
- Pros: Easy to code, debug, understand.
- Cons: Cell and Body become tightly coupled, making them trickier to re-use in other contexts (which may be irrelevant)