metaclass (metaclass) wrote,
metaclass
metaclass

.NET, NHibernate, ComponentModel

Делаю сейчас более-менее универсальный редактор сложных объектов для базы данных, на основе NHibernate и дотнетовской ComponentModel(+ всякие там IBindingList,DataGridView и прочее)

Возникла спорная мысль: разработчики и того и другого, вместо того, чтобы основательно продумать возможность наследования(или там другого способа расширять функциональность по мере надобности), пошли по пути "добавим в функциональность все, что сможем вспомнить, а определять, что именно в данный момент работает, будем конфигурацией и свойствами".
Т.е. в очень огрубленном представлении, вместо virtual метода или там передачи извне требуемой зависимости в виде интерфейса - используется обычный метод и switch/несколько if внутри.
В сочетании с недоступностью исходников (.NET 2.0) это делает работу с этим делом весьма нетривиальным занятием, по сравнению с тем же дельфи.

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

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

В .NET же есть DataSet и DataTable, но они данные физически хранят в себе и никакого переопределения им особо не требуется.

А вот гриды это мрак. Свойство - источник данных для грида имеет тип object, т.е. про строгую типизацию можно забыть. Этому свойству можно присвоить DataTable, DataSet, IList, в общем, большинство классов с семантикой "типизированный список". Если возникает задача "имея грид, добавить элемент к списку который он отображает" - это выливается в бубнопляски с указанием извне классов-обработчиков и оберток для объектов и их коллекций, вся функция которых заключается в обработке методов "добавить", "скопировать". На пару с NHibernate это создает еще больший гемор, так как NHibernate требует для коллекций интерфейсы, а их конкретную реализацию подменяет внутри чем-то своим, что не дает вызывать стандартные способы типа AddNew().

Вердикт: все это рассчитано больше на людей, не пищущих ничего универсального. Если писать в стиле: один (индус/студент/обезьяна) - одна неделя - один объект предметной области - одна форма списка - одна форма редактирования - это все вполне себе ускоряет работу, расставил проперти мышой и ладно. А если я хочу написать один редактор на все случаи жизни - мне приходится все расширение делать у себя в коде, за счет подсовывания извне классов-обработчиков.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 13 comments