Gör om gör rätt, eller?

Många OR-mappers (t.ex. NHibernate) tillåter även att man definierar mappning mha av attribut på klasser och egenskaper. Du behöver inte använda någon mappningsfil.

Är du säker på att det med Nhibernate, trode jag hade lusläst manualen :) du tänker inte på Active Record från Castle Project som iof bygger på Nhibernate

erka skrev:

Är du säker på att det med Nhibernate, trode jag hade lusläst manualen :) du tänker inte på Active Record från Castle Project som iof bygger på Nhibernate

Det stämmer att man kan skriva mappningen inuti koden.
http://www.hibernate.org/hib_docs/nhibernate/html/mapping-attributes.html

Jag tycker dock om att ha det separerat.

Det man inte vill läsa ser man nog helt enkelt inte ;) Gillar verkligen inte att ha så tight koppling mellan mina domänobjekt och min ORM, mer kludd i koden. Även om A.Record ger en starka koppling är det en av anledningarna att jag inte riktigt gillar A.Record helt ut, även om det går jävligt snabbt att utveckla med A.Record.

Men nu vet man ju att det går med NHibernate också. Känns som det är enklare att bara byta ut xml-filerna om jag vill byta ORM. Mina klasser och properties har redan för många attribut och descriptions för att jag ska vara helt nöjd ;)

erka skrev:

Det man inte vill läsa ser man nog helt enkelt inte ;) Gillar verkligen inte att ha så tight koppling mellan mina domänobjekt och min ORM, mer kludd i koden. Även om A.Record ger en starka koppling är det en av anledningarna att jag inte riktigt gillar A.Record helt ut, även om det går jävligt snabbt att utveckla med A.Record.

Nu kanske jag kommer att låta lite motsägelsefull, eftersom jag oftast är en stark påhejare av att separera lagringen från domänlagret, men jag tycker att det är viktigt att man har en pragmatisk inställning till det hela, och inser att separationen har ett syfte, men det är inte en religion. ActiveRecord och likn. har definivt en plats inom professionell utveckling, just eftersom att "det går jävligt snabbt att utveckla med A.Record" och det är ingen liten fördel. Jag hoppas och tror också att vi går mot en tid då äckelpäckel som TableAdapters etc. försvinner till förmån för ActiveRecord, LINQ to SQL m.fl.

Jag har med gott resultat använt ActiveRecord i ett antal mindre och halvstora projekt och enkelheten kan definitivt vara produktivitets- och kvalitetshöjande (mer tid till annat). Samtidigt erkänner jag gärna att jag har sprungit in i AR-väggen ett par gånger, men då är det ofta enkelt att gå över till NHibernate (i synnerhet som AR kan spara ut färdiga HBM-filer, baserade på attributen).

Jag har suttit och följt tråden nu ett tag, och tyvärr så förstår jag bara 30% utav det ni säger.
Jag står fortfarande och trampar och inte vet vad jag ska göra. Ska jag fortsätta på mitt DAL eller börja använd NHibernate, eller börja använda Gladhs EntinityMapper eller hur ska jag göra? Det har varit så lätt för mig att göra på det sättet som jag gör nu men jag vill göra om och göra rätt så jag inte behöver göra om allt igen sen. Vad tjänar jag på att göra om jag vill ha kunskap, prestanda och slippa göra om det igen? Vad är rätt eller fel enligt er?

thevice skrev:

Ska jag fortsätta på mitt DAL eller börja använd NHibernate, eller börja använda Gladhs EntinityMapper eller hur ska jag göra?

Valet mellan NHibernate och den kod som jag visade är rätt enkel, utan att vara partiskt på något som helst sätt, och fast jag vet att min kod är i absoluta topklass, så hade jag nog valet NHibernate, mest då bara för att jag skall slippa ge dig support hela tiden, det beror inte alls på att NHibernate, är bättre (hur skulle något kunna vara bättre än det jag gör?), fler som använder det (mmmm... jag, jag och jag, det blir ju några på min ORmapper det med) och den utecklas hela tiden med nya funktioner (jag kanske skall override ToString() metoden och göra något häftigt i min version...)

Så det valet är inte så svårt. ;)

I valet mellan DAL och NHibernate, så är det inte speciellt svårt om du vill få ut objekt av dina data, vill du istället ha DataTables och DataSets så skall du inte välja NHibernate utan DAL...

- M

Gladh skrev:

thevice skrev:

mest då bara för att jag skall slippa ge dig support hela tiden

Ja så kan man ju också se på det...
Men då kör jag med DAL så som jag har gjort i det tidigare inlägget. Ska jag försöka ha samma Enititer på de som behöver ta ut samma information från databasen och hur namnger ni era classer? Om vi säger att en entitet kan användas till både nyheter och gästboken vad kan ett lämpligt namn vara då? Man vet ju aldrig ifall det kommer till funktioner senare som kan använda samma entitet.

thevice skrev:

Om vi säger att en entitet kan användas till både nyheter och gästboken vad kan ett lämpligt namn vara då?

Fundera inte så mycket på vad de ska användas till, utan på vad de är för något. Kanske en NewsItem, en GuestBookEntry etc.

thevice skrev:

Men då kör jag med DAL så som jag har gjort i det tidigare inlägget. Ska jag försöka ha samma Enititer på de som behöver ta ut samma information från databasen och hur namnger ni era classer? Om vi säger att en entitet kan användas till både nyheter och gästboken vad kan ett lämpligt namn vara då? Man vet ju aldrig ifall det kommer till funktioner senare som kan använda samma entitet.

Du missade nog vad jag skrev, vill du ha ut objekt/entiteter och jobba med dem i din kod så råder jag dig till att använda någon ORMapper, det finns ett flertal, men NHibernate är väl den största produkt som är gratis.

Om du däremot vill jobba med DataTables/DataSets som du binder till dina objekt så skall du inte använda en ORMapper ut bygga ett eget DAL som ger dig tillbaka detta. Men det verkar ju som att du vill ha objekt/entiteter och jobba med, så du bör införskaffa dig en ORMapper.

- M

Jag kör med DAL, kollade på NHibernate och det verkar vara knöligare än att fortsätta på ett DAL. Har bara ett litet problem. Jag fyller en repeater med:

using (BLL.ThreadBLL bll = new BLL.ThreadBLL())
{
	using (List<Entities.ThreadEntites> threadsList = bll.GetTop4Threads())
	{
		repThreads.DataSource = threadsList;
		repThreads.DataBind();
	}
}

Men sedan när jag ska lägga till värden i mina kontroller i ItemCommand (heter det så?) så står det stilla i huvudet. Förut så gjorde jag alltid så här:

public void repThreads_ItemCommand(object obj, RepeaterItemEventArgs e)
{
	if ((e.Item.ItemType == ListItemType.Item) || (e.Item.ItemType == ListItemType.AlternatingItem))
	{
		((Label)(e.Item.FindControl("lblThreadText"))).Text = Server.HtmlEncode(Shorten(((DataRowView)e.Item.DataItem)["txtText"].ToString(), 50));
}
}

Hur gör jag nu när jag inte kan använda ((DataRowView)e.Item.DataItem)["txtText"] ?

erka skrev:

Det handlar i mitt tycke om att man i stort sett aldrig vill ha den hårda kopplingen mellan lagrena, och det är inget man ska eftersträva.

Helt klart är det en dåligt ide att lämna över ansvaret för något så viktigt som att stänga databaskopplingen till någon annan, bättre att göra det själv.

Jag skall dock erkänna att jag tidigare hade gjort ett test som visade att databaskopplingen var öppen ungefär halva tiden med en DataTable som mappade objekt mot en dataReader som mappade objekt. Men efter ha lekt med koden lite så hittade jag en märklig sak och det var hur man plockade fram FieldInfo från en type.

myType.GetType().GetFields()

Skall ge dig alla publika fält för denna typ

myType.GetType().GetFields(BindingFlags.Public)

Gör samma sak, men om jag la till den BindingFlagan så var min DataReader nästan upp till 5 gånger snabbare på att mappa data till objekt, än vad DataTablen var på att hämta data från databasen.

Och 5 gånger är rätt långtid när det gäller skalbarheten, så jag skall villigt erkänna att jag numera har tagit bort min DataTable och ersatt den med en DataReader som jag ser till att stäng i min ORMapper. Men jag gillar det inte :)

Jag försökte mig på att bygga upp en collection av egna Columner och Rader och skicka tillbaka dessa från mitt DAL istället för en DataReader, men det blev ännu långsammare :(. Så skalbarheten fick vinna över designen denna gång, jag är rädd om min databas.

- M

public void repThreads_ItemCommand(object obj, RepeaterItemEventArgs e)
{
	if ((e.Item.ItemType == ListItemType.Item) || (e.Item.ItemType == ListItemType.AlternatingItem))
	{
                ThreadEntity item = e.Item.DataItem as ThreadEntity;

		((Label)(e.Item.FindControl("lblThreadText"))).Text = item.txtText;
}
}

- M

Tack så mycket, jag märkte också nu att det inte gick att använda using så som jag gjorde. Men det går ju inte heller att köra bll.Dispose().
Ska jag skita i att det och bara ta ett nytt namn ifall jag vill ha hämta mer data från ett annat BLL?

Jag har kört med

UserBLL userbll = new UserBLL();

då jag använder fler än ett affärslager på en del sidor.

Ett tips kan vara att använda sig av Singleton när det gäller era BLL klasser.

Antingen kör man med en static om det är Winform eller HttpContext om det är Webb.

Singleton har man hört mycket om (men lärt sig desto mindre).
Singleton i samband med asp.net och webb (HttpContext), vad innebär det?

Jag vet inte om det här är en bra metod men det har fungerat för mig.

static fungerar inte så bra för Webb applikationer p.g.a. static är för hela applikationen och alla användare. Använder man sig av HttpContext så blir det enbart för den användaren på just den webbrequesten.

public static SingletonObject
{
get
{
if(!HttpContext.Current.Items["UnikNyckel"] == null)
HttpContext.Current.Items["UnikNyckel"] = new SingletonObject();

return (SingletonObject)HttpContext.Current.Items["UnikNyckel"];
}
}

Nu har jag bara skrivit ner koden minns inte exakt hur Items samlingen fungerade men något liknande.

Värt att tänka på är att singelton inte behöver vara trådsäkert alltid, bra artikel

http://www.yoda.arachsys.com/csharp/singleton.html

Jag börjar komma någon vart nu med mitt DAL. Problemet är bara att jag inte vet hur jag ska göra i DAL, BLL, UI när jag ska köra en ExecuteNonQuery?

thevice skrev:

Jag börjar komma någon vart nu med mitt DAL. Problemet är bara att jag inte vet hur jag ska göra i DAL, BLL, UI när jag ska köra en ExecuteNonQuery?

Ja du det är frågan hur dina databärare ser ut. Om jag hade gjort det så hade jag gjort så här.

Säg att du har ett formulär på sidan som skall fylla i uppgifter om en användare.

Så hade jag i min codebehind skrivit något sånt här.

private void AddUser_Click(object sender, EventArgs e){
   //-- Create a user
   User user = new User();

   //-- Fill user with data
   user.FirstName = txtFirstName.Text;
   user.LastName = txtLastName.Text;
   ...

   //-- Save user
   new Business().SaveUser(user);
}

I min BLL hade jag sedan gjort så här.

public void SaveUser(User user)
{
    //-- Create command
    IDbCommand command = new SqlCommand()
    command.Text = "dbo.SaveUser";
    command.CommandType = CommandType.StoreProcedure

    //-- Create parameter
    ...

    //-- Execute command
    new DAL(connectionString).ExecuteNonQuery(command);
}

- M