[NHibernate] AddAssembly

[whoami]

Ik ben een beetje met NHibernate aan het spelen.
Nu heb ik een dll met daarin mijn domain-model, en die dll bevat ook de mapping-files als embedded resources.

Nu is het zo dat ik, in mijn applicatie, die mapping files liefst wil inladen mbhv 'Configuration.AddAssembly()'.
Op die manier worden al mijn mapping files die zich in die assembly als embedded resource bevinden, ingeladen.
Echter, mijn probleem is nu dat ik niet direct kan vinden hoe ik de 'inlaad-volgorde' vn mijn mapping files kan bepalen. Kan dit uberhaupt ?

Ik heb nl. bv 3 classes: class A, class B, en class C.
Nu is het zo dat class B bv afhankelijk is van class A: maw: class B bevat een object van class A.

Als de mapping - file voor class B nu eerst ingeladen wordt, dan krijg ik een exception dat hij 'class A' niet kan vinden.
Als ik iedere mapping file afzonderlijk -en in de goede volgorde- inlaadt, mbhv 'configuration.AddXmlFile', dan lukt alles natuurlijk perfect.
Echter, ik wil deze manier niet gebruiken, omdat ik dan die paden naar die files moet specifieren.

Het liefst zou ik het dus voor elkaar willen krijgen mbhv AddAssembly, maar dan moet ik de volgorde kunnen specifieren. Weet er iemand hoe ik dat doe, en, als dat niet mogelijk is, weet er iemand een alternatief (dat beter is dan AddXmlFile dus).

thx.

[whoami]

Hmm, nu snap ik het niet meer.

Ik heb nog ff verder geprutst, en nu werkt het wel ?

Ik heb m'n code weer veranderd zodanig dat :
- AddXmlFile niet meer gebruikt wordt, maar AddAssembly
- De 'class' attribute uit de 'relation' weggehaald:

code:

<many-to-one name="Customer" column="CustomerId"
                     not-null="true" />

ipv:

code:

<many-to-one name="Customer" column="CustomerId" class="Customer"
                     not-null="true" />

Toen werkte het.

Daarna heb ik die class attribute er nog eens bij gezet, en het blijft werken.

Ik snap het niet.

[whoami]

Als er trouwens iemand goede tutorials weet -ik vind er niet direct- over NHibernate (en dan bedoel ik: uitgebreide tutorials, die voldoende handelen over collections/associations/etc...), dan hou ik me aanbevolen.

[tijn]

Voor NHibernate is er niet zo veel, maar zo'n beetje alles wat er over Hibernate (de java versie en dan met name 2.0/2.1) geschreven is gaat ook wel op voor NHibernate.
De .NET specifieke zaken (zoals de AddAssembly) staan in de NHibernate docs.

[EfBe]

Waarom stop je niet alles in 1 mappingfile? (en die 'fix' die je daar hebt, werkt die ook at runtime? Lijkt me sterk).

[whoami]

EfBe schreef op zaterdag 27 augustus 2005 @ 19:46:
(en die 'fix' die je daar hebt, werkt die ook at runtime? Lijkt me sterk).

Die AddXmlFile bedoel je ?
Dat is ook één van de redenen waarom ik die niet wil gebruiken

Eén mapping - file; mjah, ik heb liever een mapping-file per class. Dat vind ik overzichtelijker dan alle mappings in één file te gooien.

[ Voor 21% gewijzigd door whoami op 27-08-2005 23:40 ]

[whoami]

Wat is eigenlijk 'best practice' ?
Je NHibernate configuratie in je client-applicatie opzetten, of dit in je domain - assembly doen ?

Maw:
Zo:
_Pseudo-code

code:

ISessionFactory sessFact;

Application_StartUp()
{
    Configuration config = new Configuration();
    config.AddAssembly ("...");
 
    sessFact = config.BuildSessionFactory();

Waar die SessionFactory etc.. dus in je client - app zitten, of, doe je dit zo:

code:

Application_StartUp()
{
    domainModel.NHibernateConfig.SetUp();
}

Waarbij je dus een method aanroept die deel uitmaakt van een of andere class in je domain-model om je hibernate environment op te zetten.
De ISessionFactory is dan ook een onderdeel van die class in je domain-model.
Als je dan in je client een sessie nodig hebt, dan doe je dit:

code:

ISession s = domainModel.TheSessionFactory.OpenSession();

[EfBe]

Nou, aangezien het POCO is, is het IMHO niet meer dan logisch dat je het in je client applicatie stopt. Immers, de filosofie is dat je een assembly neemt met classes, en die via een add-on (nhibernate) mapt op een db. Die assembly en zn classes veranderen dan niet. Gebruik je je assembly in een andere applicatie opnieuw, en is hij gemapt op een andere db, dan wil je dat natuurlijk in je client app regelen.

[whoami]

Mja, de database die je gebruikt staat natuurlijk wel in je app.config file, dus dat zou het probleem niet zijn denk ik.

Aan de andere kant, zie ik mijn 'repositories' (de classes dus die ik gebruik om m'n objecten te saven/loaden/etc.... -en die dus intern gebruik maken van Hibernate- ook als een onderdeel van m'n domain model.

[tijn]

Persoonlijk zou ik de NHibernate configuratie nooit in de domain classes zetten. Sterker nog, ze hebben totaal geen referentie naar NHibernate of wat voor ondersteunende infrastructuur dan ook. Wel zet ik naast de domain laag vaak een service laag waarin transacties e.d. geregeld worden. Deze laag regelt ook de configuratie.

[whoami]

tijn schreef op maandag 29 augustus 2005 @ 14:26:
Wel zet ik naast de domain laag vaak een service laag waarin transacties e.d. geregeld worden. Deze laag regelt ook de configuratie.

Naast
Je bedoelt boven , of zie ik het verkeerd ?
Bedoel je een service-laag die eigenlijk met de domain objecten werkt, en je client-applicatie werkt dan met de service-laag ?

[Nexopheus]

=Business Delegate Pattern.

Ben zelf erg tevreden over ActiveRecord van het castleproject zie ook :
http://www.castleproject.org/index.php/ActiveRecord

[ Voor 73% gewijzigd door Nexopheus op 29-08-2005 14:37 ]

[tijn]

whoami schreef op maandag 29 augustus 2005 @ 14:30:
[...]


Naast
Je bedoelt boven , of zie ik het verkeerd ?

Niet echt boven. De domain laag met je business logica zit niet specifiek ergens boven of onder, maar staat centraal in het plaatje. Deze laag heeft geen referenties naar andere lagen (UI, Service, evt DAL). De andere lagen hebben juist allemaal een referentie naar je domain laag.

Bedoel je een service-laag die eigenlijk met de domain objecten werkt, en je client-applicatie werkt dan met de service-laag ?

Als je het plaatje zou tekenen krijg je zoiets als UI (boven) -> Service -> DAL/Database (onder). De domain laag staat hier naast als aparte laag.

[whoami]

En hoe ziet die service layer er dan ongeveer uit ?
Heb je geen klein code - voorbeeldje.

[tijn]

Nexopheus schreef op maandag 29 augustus 2005 @ 14:35:
=Business Delegate Pattern.

Ben zelf erg tevreden over ActiveRecord van het castleproject zie ook :
http://www.castleproject.org/index.php/ActiveRecord

Ik weet er eigenlijk nog niet genoeg van, maar ik zou me voor kunnen stellen dat ActiveRecord in complexe situaties te kort gaat schieten maar wellicht kun je er in de andere 80% van de gevallen wel mee uit de voeten.

[Nexopheus]

Ja, voor complexe zaken weet ik niet of ActiveRecord voldoet. Ben daar nog niet tegenaan gelopen. 80-20 regel zal ongetwijfeld van toepassing zijn

[tijn]

whoami schreef op maandag 29 augustus 2005 @ 15:11:
En hoe ziet die service layer er dan ongeveer uit ?
Heb je geen klein code - voorbeeldje.

Zie sig . (Alhoewel daar ook dingen in zitten die ik nu al weer anders zou doen).

[whoami]

tijn schreef op maandag 29 augustus 2005 @ 14:26:
Persoonlijk zou ik de NHibernate configuratie nooit in de domain classes zetten. Sterker nog, ze hebben totaal geen referentie naar NHibernate of wat voor ondersteunende infrastructuur dan ook. Wel zet ik naast de domain laag vaak een service laag waarin transacties e.d. geregeld worden. Deze laag regelt ook de configuratie.

Als je dat dan strict doortrekt, dan mogen jouw Hibernate mapping files ook niet in je domain assembly zitten...

Trouwens, wat vind je van het idee dat m'n 'Repositories' (de objecten dus die een bepaalde abstractie bieden van wat ik nu kan ophalen uit de databank), eigenlijk ook tot mijn domain-model behoren ?
Deze repositories moeten dan wel weet hebben van NHibernate, want die moeten toch weten in welke 'transactie-context' ze moeten werken ?
Zie ook:
[rml][ Alg] Domain Driven Design / Transaction Handling[/rml]

Ik heb jouw voorbeeld applicatie eens vluchtig bekeken, en ik zie dat je daar toch eigenlijk ook een probleem hebt, als je 2 (of meerdere) objecten in éénzelfde transactie wilt saven, niet ?
Je transactie-handling zit nl. in je 'CoreRepository'.

[ Voor 40% gewijzigd door whoami op 29-08-2005 21:47 ]

[tijn]

whoami schreef op maandag 29 augustus 2005 @ 20:47:
[...]

Als je dat dan strict doortrekt, dan mogen jouw Hibernate mapping files ook niet in je domain assembly zitten...

Als je het zo bekijkt niet nee, maar het is wel super handig .

Trouwens, wat vind je van het idee dat m'n 'Repositories' (de objecten dus die een bepaalde abstractie bieden van wat ik nu kan ophalen uit de databank), eigenlijk ook tot mijn domain-model behoren ?

Ik weet het niet. Ik zie domain logica als iets dat zich enkel en alleen op de business logica richt en een repository is meer toegevoegde service om je objecten op te slaan.

Deze repositories moeten dan wel weet hebben van NHibernate, want die moeten toch weten in welke 'transactie-context' ze moeten werken ?
Zie ook:
[rml][ Alg] Domain Driven Design / Transaction Handling[/rml]

Inderdaad. Die transacties zou je mee kunnen geven of, zoals ook al gesuggereerd werd, uit een of andere context trekken. Maakt me niet zo veel uit. Ik denk niet dat de repositories zelf transacties moeten initieren.

Ik heb jouw voorbeeld applicatie eens vluchtig bekeken, en ik zie dat je daar toch eigenlijk ook een probleem hebt, als je 2 (of meerdere) objecten in éénzelfde transactie wilt saven, niet ?
Je transactie-handling zit nl. in je 'CoreRepository'.

Ik bedacht me inderdaad achteraf dat dit misschien niet het meest nette voorbeeld is. Voor het gemak heb ik service en repository maar bij elkaar gegooid. Het blijft een continu proces van afwegen wat nou netjes is versus de snelste oplossing.
In een grote complexe applicatie splits ik de boel wel op waarbij de service classes wat meer user-story georienteerd zijn (en de transacties regelen) en de repositories dichter bij de gegevensstructuur blijven (bijvoorbeeld 1 repository per aggregate).

Het blijft allemaal wel een kwestie van uitproberen en kijken wat je het beste ligt. Je kunt bijvoorbeeld ook zeggen van f*ck die service laag, ik doe het wel vanuit de code-behind of de winforms code. Er zijn situaties waar dat goed genoeg is.

[Nexopheus]

Bij ActiveRecord kan het vrij makkelijk:

code:

using(TransactionScope transaction = new TransactionScope())
{
    Blog blog = new Blog();
    blog.Author = "hammett";
    blog.Name = "some name";
    blog.Save();

    Post post = new Post(blog, "title", "post contents", "Castle");
    post.Save();

    // something went wrong!!!

    transaction.VoteRollBack();
}

Dit staat dan in je Business Delegate (Services laag)

[Nexopheus]

tijn schreef op maandag 29 augustus 2005 @ 15:13:
[...]


Ik weet er eigenlijk nog niet genoeg van, maar ik zou me voor kunnen stellen dat ActiveRecord in complexe situaties te kort gaat schieten maar wellicht kun je er in de andere 80% van de gevallen wel mee uit de voeten.

Je kunt in je ActiveRecord objecten (die ActiveRecordBase implementeren) zelf HQL implementeren voor complexere queries.

C#:

ActiveRecord]
public class Market : ActiveRecordBase
{
    ...

    public Summary[] ObtainSummaries()
    {
       return (Summary[]) Execute( new NHibernateDelegate(ObtainSummariesCallback) );
    }

    private object ObtainSummariesCallback(ISession session, object instance)
    {
        ...

        IQuery query = session.CreateQuery( sbQuery.ToString() );
        
        ... set parameters ...

        IList results = query.List();

        // My personal preference is to always convert the results to something meaningfull
        // instead of returning arrays/etc

        ... convert results to summaries

        return summaries;
    }
}

Je hebt hierbij toegang tot het ISession object van NHibernate. Hoe dit zit met de automatische transaction en session management weet ik eingelijk niet.

[whoami]

Als ik het goed snap, mix je bij dat Active Record gedoe eigenlijk je 'data access' en je 'business logic'?