Как заставить Data Monder / SmartDispatcherController Castle MonoRail связываться с типами, содержащими свойства, которые являются интерфейсами? - PullRequest
1 голос
/ 20 ноября 2008

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

Реализация DataBinder по умолчанию в MonoRail будет игнорировать свойства, определенные как интерфейсы.

В идеале, мы не хотим создавать экземпляры наших классов уровня данных в MonoRail - весь смысл интерфейсов состоит в том, чтобы разделить эти проблемы.

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

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

Ответы [ 2 ]

3 голосов
/ 06 февраля 2009

Вы должны смотреть на IParameterBinder. взгляните на сообщение, которое я написал на эту тему

0 голосов
/ 24 января 2010

Как указал Кен, ваша идея может быть реализована с помощью пользовательского IParameterBinder.

Решением будет использование МОК:

  • разрешить конкретный экземпляр формы из его интерфейса
  • затем используйте IDataBinder для привязки экземпляра к параметрам запроса

Еще один будет использовать IDictionaryAdapter:

  • создать прокси-сервер dto для вашего интерфейса
  • затем используйте IDataBinder для привязки экземпляра прокси-сервера dto к параметрам запроса

Примечание: второй вариант не будет работать, если интерфейс:

  • не публично (гул)
  • имеет методы
  • или события
  • или свойства только для чтения
  • или setonly properties

Наконец, я не уверен в том, в чем заключается проблема с отображением конкретного класса в подписи контроллера.

Я сам использую конкретную форму в контроллерах, реализующих интерфейс, определенный в сервисах прикладного уровня, это позволяет мне разделять проблемы с обеих сторон:

  • на стороне контроллера - отображение Http и проверка данных первого уровня формы / команды
  • Службы прикладного уровня - это бизнес-проверка и обработка формы / команды
...