C # Как установить гибкую базу для изменения элементов управления из сборки позже?

Question

Я все еще новичок в C # и работаю над проектом, в котором мы также используем WPF и WPF DataGrid Toolkit (см. CodePlex), который еще не был выпущен в среду. Из-за характера проекта, мы уверены на 100%, что позже мы изменим некоторые элементы управления сборкой. Мои коллеги решили переопределить каждый элемент управления из сетки данных в пространстве имен нашего проекта и описать конкретный элемент управления пространством имен сборки. Поэтому вместо использования: CLR-имен: Microsoft.Windows.Controls.Primitives; сборка = WPFToolkit CLR-имен: Microsoft.Windows.Controls; сборка = WPFToolkit Мы будем использовать наши собственные пространства имен xxx.Controls и xxx.Controls.Primitives. Таким образом, было бы довольно легко изменить их элементы управления.

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

Было бы неплохо, если бы вы высказали свое мнение об этом подходе.

Answer 1

О каких изменениях вы говорите? Кажется, что пустая трата времени превентивно извлекается из каждого из классов, прежде чем вы узнаете, что вам действительно нужно изменить.

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

При вашем текущем подходе нет немедленного «это элементы управления, которые мы должны были изменить» - если вы сделаете это «точно в срок», вы сможете сказать, просто взглянув на какие производные элементы управления вы фактически должны были создать.

Answer 2

Я согласен с вами. Изменения, или, точнее сказать, изменения, могут быть любого рода. Поведение и т. Д. И изменения должны быть сделаны вовремя. К сожалению, это не мое решение. Некоторые упрямцы на работе:)

Но что меня интересует, если существует совершенно иной подход ко всей идее? Скажем, у меня есть DataGrid, проект развивается, и теперь я должен сделать некоторые радикальные изменения в поведении проверки строк DataGrid. Это также может относиться ко многим элементам управления.

Проблема нашего проекта в том, что у нас есть своего рода сложный слой доступа к данным, который не только предоставляет данные, но и фактически контролирует их. Это означает, что d ata не может быть прочитано, изменено, удалено или добавлено без включения некоторой логики, предоставляемой уровнем доступа к данным.

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