Stored procedure, bedste måde

Den hurtigste måde er at bruge Entity modellen, så bygger den et lag for dig som tager sig af alt det praktiske.

Det er uhyre nemt at arbejde med, og du slipper for at designe dine retur objekter, det sørger ORM'en for.

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/12/17/ado-net-entity-framework-tools-stored-procedures.aspx

Se flere tutorials her:
http://www.google.com/search?q=.net+entity+framework+stored+procedure+tutorial&hl=da&prmd=v&source=univ&tbs=vid:1&tbo=u&ei=y_K_TNf9FsKeOo7WrOEL&sa=X&oi=video_result_group&ct=title&resnum=5&ved=0CD4QqwQwBA

Hvis du kører ældre .net version så kig på Linq to SQL

Ok, jeg bruger visual web developer 2010, så jeg burde kunne bruge det. Er der nogle fordele ved at bruge Entity modellen frem for 3 lags modellen?

Jeg vil helst vide 100 % hvordan koden jeg benytter fungere.

Du kan selvfølgelig selv bedre styre helt hvad der sker i dit datalag hvis du designer det hele fra bunden, men det er ingen skam at bruge de udviklede teknikker som efterhånden er på et niveau hvor du ikke vinder meget ved at skrive hele koden selv.
Så efter min mening er der intet i vejen for at lave et datalag som benytter en private Entity framework klasse som tilgang til dine data.
En kæmpe fordel ved at benytte en ORM, er jo at du hurtigt opdager hvis du linker til et felt som ikke eksisterer mere hvorimod datasource["slettet_feltnavn"] ikke vil give dig nogen advarsel når du bygger dit datalag, eller hvis du benytter en SP som har ændret signatur og du ellers opdaterer din ORM, så vil du opdage problemet allerede når du bygger din klasse.

Men alt det vidste du sikkert godt ;-)

>> Jeg vil helst vide 100 % hvordan koden jeg benytter fungere.

Hvis du primært benytter SP, så kan jeg ikke se problemet, da det er SP der afgører hvordan det spiller, ORM'en gør jo ikke meget mere end at kalde din SP og returnere det der skal returneres.

Så jeg kan varmt anbefale dig at fortsætte med at bygge dit grundlag på Stored Procedures hvor det er muligt, derved bruger du din SQL Server til det den er bedst til, nemlig at arbejde med data :-)

Du kan hive data ud fra en SP på 3 forskellige måder:
- out argumenter
- results et
- return value

Her er et eksempel som viser alle 3 måder:

        SqlConnection con = new SqlConnection("server=ARNEPC2;Integrated Security=SSPI;database=Test");
        con.Open();
        SqlCommand cmd = new SqlCommand("TEST_OUTRSRET", con);
        cmd.CommandType = CommandType.StoredProcedure;
        SqlParameter prm = new SqlParameter("@outarg", SqlDbType.Int, 0, "outarg"); // <--- definer out argument
        prm.Direction = ParameterDirection.Output;
        cmd.Parameters.Add(prm);
        SqlParameter ret = new SqlParameter("@retval", SqlDbType.Int); // <--- definer return value
        ret.Direction = ParameterDirection.ReturnValue;
        cmd.Parameters.Add(ret);
        SqlDataReader rdr = cmd.ExecuteReader(); // <--- hent result set
        while(rdr.Read())
        {
            Console.WriteLine(rdr[0] + " " + rdr[1]);
        }
        rdr.Close();
        Console.WriteLine((int)cmd.Parameters["@outarg"].Value); // <--- hent out argument
        Console.WriteLine((int)cmd.Parameters["@retval"].Value); // <--- hent return value
        con.Close();

Hvis du får fejl med SqlDataReader, så er det nok fordi at der er en fejl i din kode.

Hvis du poster koden og fejlen så kan vi kigge på det.

Der er mange forskellige måder at tilgå databaser på i .NET:

* Command og DataReader
* DataAdapter og DataSet
* typed DataSet
* LINQ to SQL
* EF og LINQ to EF
* NHibernate
etc.

Jeg ville bruge enten den første eller den sidste afhængig af projektets størrelse og hvilken type operationer der skal laves.

Mange tak for svaret arne

Jeg har fundet fejlen i min kode, jeg havde lagt rdr.close i finaly, så den lavede en fejl når den prøvede at lukke readeren, når der ikke var noget data at hente.

Ok, jeg troede godt nok ikke der var så mange muligheder, jeg har kun benyttet command og datareader, så dette vil jeg helt bare fortsætte med.

bkp-> Jeg ser du flere gange nævner EF som datalag, hvorfor mener du det skal fungere som datalag? Eller måske jeg skulle spørge, hvad er din definition på et datalag når vi snakker EF?

janus_007-> Det var absolut ikke meningen at jeg ville tale for at bruge EF som datalag, men mere som et godt værktøj i dit datalag.

Jeg mener ikke at Buisnes-laget skal have adgang til EF, men de kald du gør til dit datalag kan internt i datalaget benytte EF.

Jeg har selv tidligere siddet som dba og brugte dengang Linq to SQL som tilgang til mine data i datalaget, men det var kun internt, og det gav faktisk aldrig problemer, tværtimod fik jeg klar besked når datastrukturen havde ændret sig.

I dag har jeg en masse projekter på min arbejdsplads hvor datalaget benytter Linq to SQL eller EF (alt efter hvornår det blev designet)

Håber det gav lidt klarhed over misforståelsen.

hej bkp

Jeg er selv fortaler for alt andet end sprocs efterhånden, medmindre intet andet er muligt naturligvis, jeg vil faktisk vove den påstand at dynamisk sql i DAL'en er bedre :) og det kommer fra mig som har siddet små 10år tungt på MSSQL.

Jeg startede med L2S allerede dengang da intellisensen ikke virkede og har siden været stor fortaler for brugen af ORM.

Grunden til jeg spurgte lidt ind til det du skrev, er at du netop nævner DAL'en og dermed en skarp opdeling imellem BLL og DAL. Jeg kan ikke rigtigt se hvordan det ikke skal blandes sammen når man har IQueryable! Jeg bruger et repository-pattern istedet.

Bruger du kun IEnumerable eller IList ud fra datalaget da?

janus_007>
Hej Janus
Lige kommet hjem fra Anug.dk's jQuery Codecamp :-) og får gæster om lidt, så det bliver et kort svar ;-)
Jeg bruger primært IList og benytter Linq på det returnede i mit BLL.

Ja var lige inde og chekke din blog, interessant du er på jQuery sådan der :)

Lad os diskutere videre en anden god gang :)