Обекти, използвани от ORM в комбинация с CodeContracts - гарантират инварианти

Даниел, ако не греша (мина известно време, откакто работих с NH), можеш да имаш частен конструктор и той все още трябва да се справя със създаването на твоя обект.

Освен това, защо трябва да сте 100% сигурни? Изискване ли е по някакъв начин или просто се опитвате да покриете всички основи?

Питам това, защото в зависимост от изискването бихме могли да предложим друг начин за постигането му.

Това, което МОЖЕТЕ да направите точно сега, за да осигурите допълнителна защита, е да свържете клас IIinterceptor, за да сте сигурни, че след натоварването вашият клас е все още валиден.

Предполагам, че най-важното е, че ако някой иска да обърка вашия домейн и класове, той ЩЕ го направи, независимо какво правите. Усилията да се предотвратят всички тези неща в повечето случаи не се отплащат.

Редактиране след изясняване

Ако използвате вашите обекти, за да пишете в базата данни и вашите договори работят, можете спокойно да предположите, че данните ще бъдат записани правилно и следователно ще бъдат заредени правилно, ако никой не се намеси в базата данни.

Ако промените базата данни ръчно, трябва или да спрете да го правите и да използвате вашия домейн, за да направите това (това е логиката за валидиране), или да тествате процеса на промяна на базата данни.

И все пак, ако наистина имате нужда от това, все още можете да свържете IIinterceptor, който ще потвърди вашия обект след натоварването, но не мисля, че коригирате наводняване от улицата, като се уверите, че тръбата на къщата ви е наред.

Въз основа на дискусията с tucaz, стигнах до следното, в основата си доста просто решение:

Сърцето на това решение е класът NHibernateActivator. Има две важни цели:

1. Създайте екземпляр на обект, без да извиквате неговите конструктори. Той използва FormatterServices.GetUninitializedObject за това.
2. Предотвратете задействането на изключения „invariant failed“, докато NHibernate хидратира екземпляра. Това е задача в две стъпки: Деактивирайте инвариантната проверка, преди NHibernate да започне да хидратира, и активирайте отново инвариантната проверка, след като NHibernate приключи.
   Първата част може да се изпълни директно след като екземплярът е създаден.
   Втората част е използвайки интерфейса IPostLoadEventListener.

Самият клас е доста прост:

public class NHibernateActivator : INHibernateActivator, IPostLoadEventListener
{
    public bool CanInstantiate(Type type)
    {
        return !type.IsAbstract && !type.IsInterface &&
               !type.IsGenericTypeDefinition && !type.IsSealed;
    }

    public object Instantiate(Type type)
    {
        var instance = FormatterServices.GetUninitializedObject(type);
        instance.DisableInvariantEvaluation();
        return instance;
    }

    public void OnPostLoad(PostLoadEvent @event)
    {
        if (@event != null && @event.Entity != null)
            @event.Entity.EnableInvariantEvaluation(true);
    }
}

DisableInvariantEvaluation и EnableInvariantEvaluation в момента са методи за разширение, които използват отражение, за да зададат защитено поле. Това поле предотвратява проверката на инвариантите. Освен това EnableInvariantEvaluation ще изпълни метода, който проверява инвариантите, ако бъде предаден true:

public static class CodeContractsExtensions
{
    public static void DisableInvariantEvaluation(this object entity)
    {
        var evaluatingInvariantField = entity.GetType()
                                             .GetField(
                                                 "$evaluatingInvariant$", 
                                                 BindingFlags.NonPublic | 
                                                 BindingFlags.Instance);
        if (evaluatingInvariantField == null)
            return;
        evaluatingInvariantField.SetValue(entity, true);
    }

    public static void EnableInvariantEvaluation(this object entity,
                                                 bool evaluateNow)
    {
        var evaluatingInvariantField = entity.GetType()
                                             .GetField(
                                                 "$evaluatingInvariant$", 
                                                 BindingFlags.NonPublic | 
                                                 BindingFlags.Instance);
        if (evaluatingInvariantField == null)
            return;
        evaluatingInvariantField.SetValue(entity, false);

        if (!evaluateNow)
            return;
        var invariantMethod = entity.GetType()
                                    .GetMethod("$InvariantMethod$",
                                               BindingFlags.NonPublic | 
                                               BindingFlags.Instance);
        if (invariantMethod == null)
            return;
        invariantMethod.Invoke(entity, new object[0]);
    }
}

Останалото е водопровод NHibernate:

1. Трябва да внедрим прихващач, който използва нашия активатор.
2. Трябва да внедрим оптимизатор за отражение, който връща нашата реализация на IInstantiationOptimizer. Тази реализация на свой ред отново използва нашия активатор.
3. Трябва да внедрим прокси фабрика, която използва нашия активатор.
4. Трябва да внедрим IProxyFactoryFactory, за да върнем нашата персонализирана прокси фабрика.
5. Трябва да създадем персонализиран прокси валидатор, който не се интересува дали типът има конструктор по подразбиране.
6. Трябва да внедрим доставчик на байт код, който връща нашия оптимизатор за отражение и прокси фабрика.
7. NHibernateActivator трябва да се регистрира като слушател с помощта на config.AppendListeners(ListenerType.PostLoad, ...); в ExposeConfiguration на Fluent NHibernate.
8. Нашият персонализиран доставчик на байт код трябва да бъде регистриран чрез Environment.BytecodeProvider.
9. Нашият персонализиран прихващач трябва да бъде регистриран чрез config.Interceptor = ...;.

Ще актуализирам този отговор, когато имах възможността да създам съгласуван пакет от всичко това и да го пусна в github.
Освен това искам да се отърва от отражението и вместо това да създам прокси тип, който може директно да осъществява достъп до защитените Членове на CodeContract.

За справка, следните публикации в блогове бяха полезни при внедряването на няколко интерфейса на NHibernate:

• http://weblogs.asp.net/ricardoperes/archive/2012/06/19/implementing-an-interceptor-using-nhibernate-s-built-in-dynamic-proxy-generator.aspx
• http://kozmic.net/2011/03/20/working-with-nhibernate-without-default-constructors/

За съжаление, това в момента е неуспешно за обекти със съставни ключове, тъй като оптимизаторът за отражение не се използва за тях. Това всъщност е грешка в NHibernate и докладвах за нея тук.