Старейшина
Зарегистрирован:
29 September 2002
Сообщения: 647
Примеры кода: 2
|
RE[20]: таблица->класс С# крик души |
23 July 2004 09:12 |
|
|
|
|
Ну, сценарий я обсужаю с клиентом во вторую очередь. А в первую - сущности, с которыми педстоит иметь дело, просто я мыслю таблицами.
Я тебе приводил пример, кога мышление таблицами не работает Твои приложения (как ты сам написал) только поднимают и сохраняют данные. И все. Поэтому тебе твой метод сходит с рук.
А все же инетресно - ты с клиентом прямо схему данных и обсуждаешь? Мол будет у вас такая таблица, такая связь, а мы потом на каждую таблицу по 2 формы натянем, и приложение будет готово? Может это и проканает.. В принципе, все от сложности зависит.
У меня просто был случай, когда мы просто "натягивали" данные на формы, и клиент просто завернул приложение. сказав, что в нем жутко неудобно работать, что приходится делать много лишних действий и что приложение не отражает суть процесса, а просто предоставляет кучу форм. которые сваливаются на юзера.
И вот тут началось... Тут и визарды, и долгосрочныйе бизнес-транзакции... Куча функциональности БД вообще не нашла отражения в инетрфейсе а осталась внутри, Потому как не всякую низкоуровневую логику БД нужно поднимать до уровня пользователя. Какие-то тоношения могут просто для целостности данных лежать, и, максимум, проявляться потом в каких-то отчетах.
Параллельно с этим приходилось местами нещадно переделывать схему данных, потому как с виду верные отношения между объектами очень трудно вписывались в тот процесс, который должно отражать приложение. Т.е. изначально схема была верна только для хранения данных, но не для удобной работы с ними.
Например, выяснилось, что пользователь должен уметься "одним кликом" выполнять какое-то действие, которое в старой схеме подразумевало несколько свиду несвязанных поднял-положил-связал. И на разработанной схеме этот "один клик" был полнейшим бредом. Нужно было через Ж и какие-то временные таблицы собирать данные, потом их рассовывать на свои места.
После незначительной переделки схемы, в ходе которой....ну, скажем так, сместились акценты в отношениях, один клик получился в 5 строк. И при этом гибкости схема не утртила.
Это я все к тому, что все объекты и отношения ВСЕГДА вылазят из пользовательских сценариев. Схема должна адаптироваться под юзабилити, а не наоборот. Анализ прецедентов или их синонимов в разных методологиях - это первый пункт в процессе разработки.
We take I.T. easy!
|
|