Я могу только сказать вам для Java, почему он не поддерживает типы примитивов в дженериках.
Сначала возникла проблема, заключающаяся в том, что вопрос о том, чтобы поддерживать это каждый раз, вызывал дискуссию о том, должны ли Java иметь примитивные типы. Что, конечно, мешало обсуждению актуального вопроса.
Во-вторых, главная причина не включать это было то, что они хотели двоичной обратной совместимости, чтобы она работала без изменений на виртуальной машине, не знающей обобщений. Эта причина обратной совместимости / совместимости миграции также является причиной того, что теперь API-интерфейс Collections поддерживает дженерики и остался прежним, и нет (как в C #, когда они ввели дженерики) полного нового набора универсального API-интерфейса Collection.
Совместимость была достигнута с помощью ersure (общая информация о параметрах типа удалена во время компиляции), что также является причиной того, что вы получаете так много непроверенных предупреждений о приведении типов в java.
Вы все еще можете добавить усовершенствованные дженерики, но это не так просто. Простое добавление информации о типе add runtime вместо удаления не будет работать, так как это нарушает работу исходного кода & amp; бинарная совместимость (вы не можете продолжать использовать необработанные типы и не можете вызывать существующий скомпилированный код, потому что у них нет соответствующих методов).
Другой подход - тот, который выбрал C #: см. Выше
И автоматическая автобокс / распаковка не поддерживалась для этого варианта использования, потому что автобокс стоит слишком дорого.
Попробуйте использовать шаблон состояния. Затем вы можете поместить логику в свои внутренние классы. Я использую это довольно часто, когда есть логика, которая должна содержаться в "enum". Например, в приведенном ниже коде есть абстрактная функция IsReadyForSubmission (), которая затем реализуется в каждом из вложенных подклассов (показан только один). HTH
[Serializable]
public abstract partial class TimesheetStatus : IHasIdentity<int>
{
public static readonly TimesheetStatus NotEntered = new NotEnteredTimesheetStatus();
public static readonly TimesheetStatus Draft = new DraftTimesheetStatus();
public static readonly TimesheetStatus Submitted = new SubmittedTimesheetStatus();
//etc
public abstract int Id { get; protected set; }
public abstract string Description { get; protected set; }
public abstract bool IsReadyForSubmission();
protected class NotEnteredTimesheetStatus: TimesheetStatus
{
private const string DESCRIPTION = "NotEntered";
private const int ID = 0;
public override int Id
{
get { return ID; }
protected set { if (value != ID)throw new InvalidOperationException("ID for NotEnteredTimesheetStatus must be " + ID); }
}
public override string Description
{
get { return DESCRIPTION; }
protected set { if (value != DESCRIPTION)throw new InvalidOperationException("The description for NotEnteredTimesheetStatus must be " + DESCRIPTION); }
}
public override bool IsReadyForSubmission()
{
return false;
}
}
//etc
}
Почему вы так усложняете это? Это действительно просто.
Отображение выглядит так:
<property name="OrganizationType"></property>
Свойство модели выглядит так:
public virtual OrganizationTypes OrganizationType { get; set; }
Enum выглядит так:
public enum OrganizationTypes
{
NonProfit = 1,
ForProfit = 2
}
NHibernate автоматически все это вычислит. Зачем печатать больше, чем нужно ????