Nyt system, valg af komponenter/udviklingsmetoder

4 projekter:
* desktop GUI via WPF (ikke win forms)
* web GUI via ASP.NET MVC (ikke web forms)
* BLL
* DAL via enten MS EF eller NHibernate

NUnit til test.

Et eller andet DI framework (f.eks. Spring.NET men der er ogsaa andre gode) til at lime det sammen med.

Jeg vil begynde at kigge lidt på WPF. Det lader til at WinForms efterhånden kaldes "lagacy" rundt omkring, så det er nok ikke en dum ide at bruge WPF. Jeg kan også se at Developer Express kan levere nogle komponenter til platformen så det er jo lækkert.

Mht. datalaget så har jeg tidligere arbejdet med noget lignende, kan bare ikke helt huske hvad det hedder. Her løb jeg dog ind i at blive nød til at lave min egen "Model" da jeg nødigt ville have klasser fra dette system i BLL. Jeg hentede altså dataene med noget ala NHiberate men loadede herefter disse data over i min egen model som jeg kunne arbejde videre med. Er det fremgangsmåden eller bruger man ting fra fx NHibernate i sit BLL?

NHibernate er DAL ikke BLL.

Der vil blive lavet win forms i rigtigt mange aar endnu.

Men naar nu du eksplicit spoerger efter noget super duper brand nyt, saa synes WPF oplagt.

Jeg er med på at NHibernate er DAL og ikke BLL.
Er det ikke hvor der bliver genereret en model af databasen og NHibernate benytter sig så af objekter af denne model?

Hvis det er sådan det hænger sammen, så mener jeg blot, at vi lavede vores egen model fremfor at bruge "NHibernate"s model og når vi hentede data fra databasen gik det sådan her:
DB -> "NHibernate model" -> Egen Model -> BLL -> UI

Mht. om jeg skal benytte WPF eller WinForms så kunne jeg godt tænke mig at høre hvad du hælder til? Jeg tænker at jeg skal bygge noget op som kan holde i mange år, 10+. På den anden side står jeg også med nogle kollegaer som jo også skal sætte sig ind i WPF og det behøver ikke være lige nemt for alle

NHibernate bygger paa at du har din objekt model og din database struktur og at du laver en XML mapping fil som mapper mellem dem.

Eneste restriktion er at du skal erklaere properties virtual hvis du vil bruge lazy loading

Saa:

din db---(via nhibernate)--->din model

Hvis eneste kriterie er at det skal se nyt og smart ud, saa er WPF det rigtige valg.

Har du restriktioner via skill sets tilraadighed etc., saa skal der vurderes og traeffes et valg.

Hej Poul
Nogen udviklere mener stadig at man skal opdele dal og bll, efter mange års overvejelser er jeg kommet frem til at det er dobbeltarbejde. Det er spild af tid og god funktionalitet at have et dal som på en eller anden måde omdanner til egen model, medmindre man kører legacy dal.

Nu til dags hvor man netop har Entity Framework eller for den sags skyld det noget mere simple Linq to Sql(det kræver dog en mere specifik db-model), eller sågar NHibernate, giver det ingen mening at køre lagdelt imellem datastorage og businesslogic når det kommer til databaser.

Dvs. find et godt framework, EF eller Nhibernate som Arne foreslår og jeg siger så "glem" datalaget og oldschool DAL'en :)

Og igen.. brug Spring som DI, eller Structuremap, jeg har arbejdet med begge og foretrækker StructureMap da det er modnet bedre og mere specifikt til DI end Spring.NET

Kogt ned 2 lag... et præsentationslag og et forretningslogik (inkl. DAL)
Måden jeg ville bygge det på er ved at lave et WCF-servicelag, dette lag skal fungere som BLL (med det imaginære DAL).

Og så have et presentationlayer...
WCF-servicen kan du så trække på igennem både Web og Win om det lige skal være MVC og WPF, må komme an på udviklernes færdigheder og tidsforbrug.

Det er ikke nogen naturlov at man skal have et bestemt antal lag. 3 er almindeligt men alt i 2-6 (per tier) kan give fin mening for et specifikt problem.

Men den kendsgerning at data access kraever betydeligt faerre linier kode med ORM goer ikke et DAL er overfloedigt.

Man valeger ikke at lave DAL fordi der er en stor maengde kode i forbindelse med data access.

Man valeger at lave DAL fordi de separerer data access koden ud fra anden kode.

Det er maaske ikke saa synligt at have 100 metoder som hver har 1 linie der er EF/NH specifik som at have 100 metoder som hver har 10 linier ADO.NET Command SQL linier. Men reelt er der inge forskel - uanset om det er 1 eller 10 linier skal man ind og modificere alle 10 linier, hvis der skal aendres i data access teknologien.

Hvis de 100 metoder har en ref til et interface som instantieres med en konkret implementation via konfiguration, saa er der ingen aendringer. Det kaldes et DAL.

Janus:
Jeg er tilhænger af at have 3 lag, jeg kan godt lide at adskille dataacesss og bll, så tror jeg holder den ide :)

Arne:
Jeg vil lige prøve at rode lidt med Nhibernate, dog vil jeg lige høre om der er stor forskel på EF og NHibernate og hvorfor jeg måske bør vælge det ene fremfor det andet.

Den anden ting jeg lige vil have på plads:
Er der intet i vejen for at lave en WinForms applikation og forvente at den sagtens kan køre fint de næste 10 år og stadig være tilfredsstillende. Du ved selvfølgelig ikke hvordan fremtiden ser ud til den tid, men hvis der ikke er noget der taler VILDT for at vælge WPF så tror jeg næsten det ville være den bedste løsning når jeg tænker på at kollegaerne også skal sættes ind i det

Nu er jeg ikke ekspert i EF og NH, men et par betragtninger:

EF er fra MS d.v.s. at man skal ikke installere noget ekstra for at bruge det, der er VS wizard etc.. Det er en fordel for EF.

NH er betydeligt mere modent end EF (EF er fra 2008 mens NH er fra 2005 og bygger paa Java Hibernate som er fra 2001). Det er en fordel for NH.

Jeg er ret sikker paa at win forms vil vaere supporteret i nyeste .NET version i 2021 (men du skal nok ikke forvente mange nye features).

En af grundene er at at win forms er et ret tyndt lag oven paa Win32 API.

Det koster ikke ret meget at have det tynde lagi .NET.

Og hvis man fjernede Win32 API i Windows X, saa ville ingen windows apps undtagen .NET WPF apps virke paa den.

Det ville vaere kommercielt selvmord for MS at fjerne det.

Jeg ville ikke blive overrasket hvis win forms var supporteret i 2031.

Som sagt, jeg deler ikke længere den gamle opfattelse af at benytte sig af 3-lags arkitekturen, det er muligt nogen opfatter mig som radikal når det kommer til udvikling :)

Når du bruger EF eller Linq to Sql, behøver du ikke noget datalag i traditionel forstand. Jeg havde også lidt svært ved det lige i starten og ledte længe efter et pattern som kunne håndtere det "nye smarte", jeg fandt på at bruge repository pattern http://martinfowler.com/eaaCatalog/repository.html , hvilket også ofte ses ifb. NHibernate.
Men nu efter... som jeg tidligere nævnte, er jeg kommet til den overbevisning at det er overflødigt og giver kun anledning til kompleksitet. Jo flere lag jo højere kompleksitet!

Hvis du nu stadig insistere på 3-lag så kan jeg anbefale et repositorypattern :-)

Dataaccesskoden ligger "skjult" i EF hvilket er derfor at MS opfordrer til at bruge EF "as-is" og ofte anbefaler "Model-first"-princippet.

Den gamle begrundelse med "jamen hvis der skal rettes i dataaccess....", ja den har jeg snart hørt på i 15år :) og ikke en gang er det sket.
Skulle det nu alligevel ske, så findes der EF-drivere til både Oracle og MySql (hvis man af ukendte årsager ville vælge MySql)

Når det kommer til Winforms kontra WPF bør du nøje overveje at ikke at vælge WPF, jeg synes du skal kigge på det inden du vælger det fra. Det er sku bare lige lidt nemmere at lave et fedt interface end Winforms :)

Hvis man designer software efter at der nok ikke skal aendres i teknologien, saa er der maneg ting som er nemt (men dyrt hvis ens antagelse ikke holder).

Men det sker at folk skifter data access teknologi.

.NET har eksisteret i 9 aar og MS har allerede skiftet foretrukket data access teknologi 3 gange: data set i 1.x -> typed data set i 2.0 -> LINQ to SQL i 3.5 -> EF i 3.5SP1/4.0.

Jeg synes du drejer mit argument en smule nu, jeg skrev mht. EF eller NHibernate, L2S findes nu stadig i 4.0 endda med nye features :)

Min hovedpointe er blot at man måske fraskriver sig mange gode ting ved at have et datalag hvor entitetkonverteringen foregår og alt der kommer ud derfra er poco's. Man mister IQueryable på den måde og det er da synd synes jeg.

Jeg har igennem de seneste projekter med repository pattern udstillet IQueryable, men derimod haft mine insert, update og deletes implementeret.

.NET 1.x untyped data set findes stadig i 4.0, men det aendrer ikke ved at MS har skiftet foretrukken teknologi i gennemsnit hver 3. år.

Java har også skiftet en del. Java EE er skiftet fra entity bean til JPA. Og ved siden af har man JDO, Hibernate og RowSet.

Det er særdeles realistisk at der kan ske et skift af ORM teknologi i et projekts levetid.

Men ja - man fraskriver sig nogle muligheder ved at bruge DAL. Det gør man altid med encapsulation. Det er fordelen ved det. Men altsaa ogsaa ulempen.

EF 4.0 understoetter ioverigt POCO's og hvis man ikke er purist kunne man maaske godt lade et DAL returnere IQueryable.

Tak for en god snak i to. Jeg er dog stadig i tvivl om hvad jeg skal benytte hehe.
Jeg tror jeg vil arbejde videre med EF da det som nævnt er et MS produkt og jeg stoler på at dette vil blive understøttet ordentligt fremadrettet.
Mht. WPF eller WinForms ved jeg ikke endnu. Jeg kan godt lide at rode med det og prøve nye ting men jeg er ikke sikker på at mine kollegaer deler samme holdning.
Med mindre i har flere guldkorn i gerne vil af med, så smid et svar så får i nogle point :)

Janus:

Dataaccesskoden ligger "skjult" i EF hvilket er derfor at MS opfordrer til at bruge EF "as-is" og ofte anbefaler "Model-first"-princippet.

Jeg står i den situation at jeg har en kæmpe database som det ikke er planen at lave om i. Den bærer meget præg af at tidligere udviklere ikke har syntes om at bruge fremmednøgler overhovedet.
Er det muligt bare at smide en EF model op af den eksisterende DB og bygge videre derfra?

Derudover kunne jeg godt tænke mig et eksempel på hvordan din 2-lags struktur med EF virker, det kan jo være jeg bliver overbevist omkring din tankegang.. må jo nok indrømme at jeg ikke har set dataaccess blive skiftet ud sønderligt ofte

Ja selvtak for god snak til dig og Arne  :)

Hvis du ikke har nogle fremmednøgler i db'en så kunne du jo oprette dem, jeg synes det er virkelig dårlig skik og totalt mangel på forståelse at bygge db'en op uden dem, de skulle skamme sig de udviklere :)

Ellers må du selv bygge dine relationer i EF, det er nu heller ikke så svært.

Mht. at springe DAL eller Repository over, så går det jo kort forklaret ud på at anvende ISession, DataContext eller ObjectContext direkte i WCF-servicen.

Typisk vil man have et Repository alá:

class SomeRepository : IRepository

void Insert(Entity.Foo e)
{}
void Update(Entity.Foo e)
{}
void Delete(Entity.Foo e) eller måske void Delete(int fooId)
{}
og så nogle metoder GetByXXXX/ FindByYYYY til udtræk: (trivielt og stupidt imho)
IList<Foo> GetFooByNameStartWith(string name)
{}
IList<Foo> GetFooByNameEndsWith(string name)
{}
Foo GetFooById(int fooId)
{}

eller hvis man vil arbejde med en mere fleksibel model:
IQueryable<Foo> GetFoo()
{
using(var context = new Context())
{
.....
}
}

og så via sit bll/ service lag kalde repository....

someRepository.GetFoo().Where(x => x.Name.StartsWith("j"));


Det er sådan et repository pattern med Linq normalt ser ud, problemet med den tilgang er at du afskærer dig selv fra loadoptions/ eager loading og det er netop det du gerne vil bruge i dit bll/ service-lag såsnart du skal hente data ud fra mere end 1 tabel og det skal performe godt.

Et andet og lign. eksempel på Repositorypattern: http://blog.stevehorn.cc/2009/07/opinion-on-repository.html

Janus:
Helt enig med databasen, det er håbløst at arbejde med, men at rydde bordet og starte forfra med databasen er meget uoverskueligt.
Jeg ved ikke om jeg tænker for simpelt men jeg tænker at gøre følgende (det er sikkert hvad i andre har nævnt som en mulig løsning, men nu spørger jeg bare lige dumt)

Min plan:
DAL = EF
BLL = fx:

function GetName(byval ID as integer) as string
    'Noget Linq to Entities som returnerer et navn udfra et ID


UI:
button1_click
      textbox.text = BLL.GetName(123)

For simpelt eller okay? :)

Hej Poul

Det kan man snildt og det er også hvad jeg stort set selv ville gøre :)

Det fleksible Repository pattern lægger op til den fremgangsmåde. Altså med IQueryable på GetFoo som forklaret tidligere.

Tjek evt. denne her: http://www.codeguru.com/csharp/csharp/cs_linq/article.php/c18211/Applying-The-Repository-Pattern-on-LINQ-and-ADONET-Entity-Framework-4.htm

Lige et sidespørgsmål.
Når man skal databinde fx et gridview, bruger folk så nogensinde en "DataSource"? Altså her mener jeg at man kan klikke på gridviewet og konfigurere en datasource og så laver den selv de columns der skal til osv.
Jeg ville nu hellere binde gridviewet i codebehind, men hvad gør folk egentligt?

Muligheden findes så selvfølgelig er der også nogle der bruger den og det er bestemt også en god og ikke mindst hurtig måde at gøre tingene på og det fungerer fremragenende til fremvisning af Visual Studio og ASP.NET - selv er jeg dog ikke den store tilhænger, nok primært fordi det er at blande for meget kode med designet.

Hej Poul
Enig med keysersoze i den betragtning.

Du vil få en stærk binding imellem presentation og data og når du samtidigt vil udvikle til både Win og Web så er det en skidt idé.

Det er bedre at holde et fælles lag som du kan tilgå både fra web og win :)

Kan blive ved med at finde på spørgsmål hehe, men det er nok på tide at lukke den her tråd.
Smid et svar jer der ønsker point :)

Janus:
Mit eksempel fra tidligere hvor jeg ville returnere et navn er okay. Men hvad nu hvis jeg vil returnere et objekt, f.eks. "Person"? Vil du så blot bruge den Model som findes i EF?
Jeg har prøvede noget der mindede om EF tidligere, men her fandtes der en masse properties som jeg slet ikke skulle bruge under det genererede objekt. Det gør selvfølgelig ikke noget hvis man ikke bruger dem, but still. Bruger du blot det objekt fordi du bygger jo ikke din egen model kan jeg forstå :)

Hej Poul

I sådan tilfælde som her vil jeg bruge objektet direkte, hvorfor ikke?
Det er jo din "Model" som er modelleret, det tjener ikke rigtigt noget formål at konvertere til andre objekter.

Objekterne er "rene" dvs. de ikke indeholder tilsatte properties/ metoder.

Eksisterende databaser er et kendt problem.

ORM virker typisk bedst med databaser designed til denne tilgang.

Man kan normalt altid faa sit ORM til at mappe til databasen uanset struktur.

Men nogen gange kan det resultere i meget ineffektiv SQL.

Det kan anbefales at undersoege hvad ens ORM faktisk udfoerer af SQL aetninger.

function GetName(byval ID as integer) as string

er en glimrende DAL funktion for et ikke-objektorienteret sprog.

Jeg synes absolut ikke at den passer som BLL metode i et objektorienteret sprog.

GetName er ikke en business funktion.

Og der returneres ikke et model objekt.

Arne:
Tror også lige jeg vil overveje om en ORM er løsningen når jeg står med en ret forfærdelig database, men det vil vise sig :)

Mht. GetName() hvad foreslår du så jeg gjorde? Returnerede et helt objekt istedet for bare navnet og hvordan skulle jeg få fat i sådan en metode fra UI hvis den ikke passer som BLL metode? Jeg kan jo ikke kalde direkte til DLL fra min UI, sådan har jeg aldrig gjort i hvert fald

Hvis dit problem er ren CRUD uden business logic overhovedet saa kan:

PL-DAL

faktisk vaere en mulighed.

Men er der noget business logic, saa boer metode navn afspejle en business funktion.

LookupCustomer, SearchForOrders etc..

Og jeg ville forvente at den returnerede et objekt a la Customer, List<Order> etc..

Smid et svar jer der ønsker point :)

svar