Nano Hash - криптовалюты, майнинг, программирование

Свободный NHibernate: подклассы внутри подклассов

У меня есть разные виды товаров. Теперь в AppProduct есть разные виды величин - умножение значений, список значений и т. Д.

   public class Product : Entity
   {
   }
   public class Quantity: Entity
   {
   }
   public class ListQuantity : Quantity
   {
      public virtual IList<int> Quantities { get; set; }
   }
   public class MultiplierQuantity : Quantity
   {
      public virtual int Multiplier { get; set; }
   }
   public class AppProduct : Product
   {
      public virtual Quantity Quantity { get; set; }
   }

Возникает вопрос: возможно ли вообще отображение с FNH или NH? В частности, с автоматическим отображением. Для меня было бы естественным отображать продукты в их собственных таблицах, но количество было бы частью таблицы AppProducts ... то есть с разграничением.

Я безуспешно пробовал разные Subclass, JoinedSubclass и т. Д., Каждый с разными исключениями NH. Это работает только тогда, когда обе иерархии по умолчанию сопоставлены с объединенным подклассом. Однако автоматическое сопоставление не может автоматически отображать IList [int]. Если я установлю IList [Product] (для тестирования), все будет работать отлично. Если я попытаюсь сохранить IList [int], используя это сопоставление:

   public class ListQuantityMap : IAutoMappingOverride<ListQuantity>
   {
      public void Override(AutoMap<ListQuantity> mapping)
      {
         mapping.HasMany(x => x.Quantities).AsElement("QuantitiesId");
      }
   }

в случае сбоя с System.Xml.Schema.XmlSchemaValidationException: элемент 'class' в пространстве имен 'urn: nhibernate-mapping-2.2' имеет недопустимый дочерний элемент 'bag' в пространстве имен 'urn: nhibernate-mapping-2.2'. Список возможных ожидаемых элементов: «мета, подзапрос, кеш, синхронизация, комментарий, туплайзер, идентификатор, составной-идентификатор» в пространстве имен «urn: nhibernate-mapping-2.2».

хотя единственная разница в экспортируемых Orders.Core.Quantity.hbm.xml - это тип класса один-ко-многим ... т.е. NHibernate не жалуется на мешок почти в том же отображении.
(примечание: вероятно, это ошибка, исправленная в недавнем FNH, issue # 299).

В любом случае, объединенный подкласс - не идеальное решение. Я даже думаю о том, чтобы сделать просто компонент в AppProduct и сам создать соответствующий количественный объект, когда назначено свойство QuantityType ... хотя это слишком странно. А может, переход на Linq2Sql поможет? ;-)


  • Вероятно, было бы полезно, если бы вы включили схему db, с которой пытаетесь сопоставить эту модель. Я изо всех сил пытаюсь понять, каковы ваши намерения без этого. 29.08.2009
  • У меня нет схемы, она создается на основе сущностей и сопоставлений, сгенерированных FNH. Так что это может быть что угодно. Кроме того, проблема с ручным исключением HasMany была ошибкой, исправленной в последних версиях FNH (вставленное переопределение во все подклассы). 31.08.2009

Ответы:


1

Я не уверен, чего вы пытаетесь достичь. Похоже, с вашей объектной моделью могут быть проблемы. Например, похоже, что у вас есть класс количества (в отличие от стандартного свойства, производного, возможно, от int). Возможно, вы захотите переосмыслить это.

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

Я думаю, что проблема, скорее всего, связана с вашей объектной моделью, а не с проблемой Fluent-NHibernate.

Вы можете найти официальную страницу Fluent о сопоставлениях подклассов по адресу http://wiki.fluentnhibernate.org/Fluent_mapping .

31.08.2009
  • Это не количество, это допустимые количества, которые могут быть * n или 1,2,3, ... n, следовательно, разные классы стратегий (и, возможно, я добавлю третью стратегию позже). Эти разные классы помогают с методами, подобными GetNextAllowedQuanity (). У меня может быть 1 компонентный класс, и он будет работать ... но в стиле switch (amountStrategy), который не очень хорош и не объектно-ориентирован. 31.08.2009
  • В порядке. Я все еще не совсем понимаю. Когда вы говорите допустимые количества, вы имеете в виду какой-то тип количества? Это что-то вроде единицы измерения (например, каждая, унция, футляр и т. Д.)? Похоже, вы можете сказать, что для определенного типа продукта вы хотите иметь возможность связать список допустимых типов для определенного количества. 31.08.2009
  • Ну, на самом деле мои количественные типы выражены как классы в примере кода ... Для каждого продукта мне нужен один количественный тип, потому что это может быть либо множитель, либо список значений. Итак, product1 будет иметь поле Multiplier = 5 и никаких значений в таблице AllowedProductQuantities (ProductId, Value), а product2 будет иметь Multiplier = null и несколько значений в таблице AllowedProductQuantities. Теперь я хотел бы увидеть, как сделать количество КОМПОНЕНТОМ продукта, чтобы у меня было поле Product (Multiplier), а не таблица ProductMultiplers с (ProductId, Multiplier). 04.09.2009
  • Новые материалы

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

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

    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..

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

    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..

    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..

    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..