Кросс-DDL расширение Entityclass

Question

Что я хочу архивировать:

• Сервисная сборка (проект), которая содержит EntityClasses - чистые данные.
• Сборка GUI, которая расширяет эти сущности для своих собственных потоков - Информация о времени выполнения для GUI.

Что я пробовал:

• Деривация (Gui определяет класс ExtendedEntity: Service.BaseEntity)

  кажется мне наиболее распространенным и единственно возможным способом, но:

  Преобразование Service.BaseEntity в ExtendedEntity после извлечения данных из службы является болезненным. можно «обойти» это, используя отражение для создания новых экземпляров ExtendedEntity на основе экземпляров базовых объектов, но это не может быть «правильным» решением.

• Частичные занятия

  это именно то, что я ищу, за исключением того факта, что он не работает кросс-сборки.

Буду очень признателен за любые подсказки, помогающие мне найти правильное и чистое решение без обмана отражения =)

Answer 1

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

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

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

Сплоченность и связь

Что такое внедрение зависимостей

Что такое хороший учебник по шаблону репозитория

Answer 2

Возможна ли декомпиляция?Если да, вы можете использовать, например, PostSharp или Mono Cecil , чтобы переписать рассматриваемые классы и добавить туда код, который вы хотите получить.Меня интересует, почему вы не хотите использовать стандартный подход ОО, такой как деривация.Это определенно не взлом.

Самым «чистым» решением ОО является использование агрегации и инкапсуляция классов Entity внутри объектов, где вы можете полностью контролировать, что вы можете делать с данными и как вы хотите манипулировать ими или запрашивать их.Вы достигли «небес», когда вашему классу агрегации больше не нужно раскрывать внутренний класс Entity, потому что ваш класс достаточно мощный, чтобы поддерживать все необходимые операции с правильными абстракциями.

Если классы, которые вы хотите расширить,тогда вам нужно хорошо подумать, почему авторы этих классов не хотели, чтобы вы их расширяли.

У Эрика Липперта есть хорошая запись об использованиизапечатанное ключевое слово.

...

Теперь я признаю, что разработчики - очень практичные люди, которые просто хотят добиться своей цели.Конечно, иметь возможность расширять любой класс удобно.Типичные разработчики говорят «IS-A-SHMIZ-A, я просто хочу шлепнуть Confusticator в класс Froboznicator».Этот разработчик может написать хеш-таблицу, чтобы сопоставить одну с другой, но тогда вам придется задуматься о том, когда удалять элементы, и т. Д., И т. Д. - это не ракетостроение, а работа.

Очевидно, что здесь есть компромисс.Компромисс заключается в том, чтобы позволить разработчикам сэкономить немного времени, позволяя им рассматривать любой старый объект как пакет свойств, с одной стороны, и разработать хорошо спроектированную, OOPtacular, полнофункциональную, надежную, безопасную, предсказуемую, тестируемую среду вразумное количество времени - и я собираюсь сильно наклониться к последнему.Потому что ты знаешь что?Те же разработчики будут горько жаловаться на то, что предоставляемая нами среда замедляет их, потому что она полусырая, ломкая, ненадежная и не полностью протестирована!

...

Ваш, Алоис Краус

Answer 3

Ваша сборка GUI может определять методы extension для классов сущностей.С соответствующими директивами using это будет означать, что потребительский код не будет знать или не заботиться о том, где методы были фактически определены.

Небольшое раздражение вызвало бы отсутствие расширения properties ,поэтому даже вещи, которые являются концептуальными свойствами, должны быть реализованы как методы.

Это будет выглядеть примерно так:

• В сборке службы

  public class FooDTO
  {
      public string Name { get; set; }
  }
  

• В сборке GUI

  internal static class Extensions
  {
      // Artificial example!
      public static int GetNameLength(this FooDTO foo)
      {
          return foo.Name.Length;
      }
  }
  
  // Consuming code
  int myFooNameLength =  myFooDTO.GetNameLength();