Funderar på det här med skiktad lösning som för mig är lite nytt, (ska snart läsa en bok om detta)
Hur gör ni då ni skickar datat mellan de olika lagren.
Kan någon visa ett litet lättare exempel.

[presentationslager]
-ListBox kontroll
-presenterar data

hur skickar jag data mellan dessa lager på bästa sätt ?

[affärslager]
-bearbetar data
-skickar data till presentationslagret


[datalager]
-sql frågor

Kalle,

Det beror helt o hållet på sakens syfte, men ett typiskt exempel. (oBS! ingen regel) är att göra typ så här.


PRES
-------
<code>

ArticleInfo articleInfo = new ArticleInfo();
articleInfo.Number = ArticleNumberTextBox.Text;
articleInfo.Name = ArticleNameTextBox.Text;
...
Article.Save(articleInfo)
</code>

BOL
-------
<code>
public void Save(ArticleInfo arcitcleInfo)
{
'gör saker om du måste med Artikel informationen, kanske avrunda eller kolla så artiklen inte redan finns etc...

if(!ArticleManage.Exist(articleInfo))
ArticleManager.Save(articleInfo);
}
</code>


DAL
------
<code>

public void Save(ArticleInfo articleInfo)
{
SqlConnection.....
...
'Plocka ut alla värden och lägg dem i SqlParameters
'...
'kör Storedprocedure, eller dynamisk insert sats...
command.ExecuteNoQuery("Sp_SaveArticel"........);
}
</code>


ArticleInfo är i detta fall en enitet så kallad BE (Business Entity) som bara består av properties med info
ang Articlen.

Namnen jag angav ovan är ingen Standard utan du väljer lite själv vad du tycker passar bäst.

Mvh Johan



</code>

Om jag fattat rätt så skapas objekt som passas mellan lagren.

Kanon bra...

Har du några bra tips på sidor med nyttig info om detta.

Kalle,

Nja, har inga direkt länkar som jag kan rekomendera, det är så att 3 skitad arkitektur har som med allt annat undantag, olika mönster etc... Det bästa är nog att läsa teorien om 3 skikt, och sedan kolla runt efter klassiska design pattersn för skiktade lösningar.

Mvh Johan

Ett exempel från MSDN, det är en walkthrough som tar dig igenom hela processen.

Skapa skiktad lösning
Använder WS
Går att koppla både http och windowsform UI till ganska smärtfritt.

msdn.microsoft.com/library/default.asp?url=/library/en-us/vsintro7/html/vbwlkCreatingDistributedWebApplicationWalkthrough.asp

faktum är att MSDN har grymt mkt nice info att plugga igenom för den vetgirige

Johans exempel är helt ok...men bara ett ord på vägen Kalle. Se till att alltid programmera mot interface och inte konkreta klasser. På detta sätt kan du enkelt byta ut en komponent t ex i ditt domain logic lager från att vara en egen skriven klass som innehåller logik till att vara en klass som anropar logik i t ex en webservice. Detsamma gäller också data access lagret. Idag kanske du använder dig av plain sql men i framtiden kanske du vill testa ett O/R mappningsverktyg eller någon annan teknik...eller kanske t om en annan typ av datakälla. Så se till att hålla dig till interface överallt så får du en pluggbar och interface driven arkitektur.

Ta en titt på begreppet dependency injection, eller inversion of control som det också kallas. Med hjälp av denna teknik kan du nå väldigt långt vad gäller löskopplade system.

/Nils

Är lite nyfiken ang löskopplade system. Min erfarenhet är att när man oftast kanske kommer till en sådan sits där saker och ting behöver ändras omfattande, så mkt att APIer och rubbet oftast byts ut eller att man bara bygger på det som finns. Jag har än idag inte hmanat i en sits där jag måste bygga lagren med Interface. Jag förstår poängen men själv inte haft nyttan av det än. Dock nyttjar jag Interface i de mer bakomliggande sakerna för att kunna köra olika pluggbara providers m.m. Ex transparanta datakällor.
Entitererna byggs ut, kanske tom ändras, databasen ändrar mönster (om bra skäl att plugga loss DAL biten, fast bara om man kan leva på de APIer man har.) Då projekt utvecklas med tiden så är det rätt valigt att dess design och mönster också ändras. Varje system vi byggt har oftast blivit byggda på gammal teknik (eller rättare sagt, tekniken har blivit gammal) så det inte skulle gå att migrera till den nya. Ex ASP 3 till ASP .Net. Sedan har vi ju de trevliga trenderna. :-) wooo älskar dem, de som ställer till med problem eller to m. nytta.

Tabel driven design, Domän driven design. Och nu mer o mer SOA samt TDD, Agile, XP etc.... Som börjar bli en ny trend åter igen. Vilket i of är kul då de faktiskt inte testats tillräckligt mkt än att man kan säga om de verkligen fungerar.

Återigen till interfacen, det lustiga eller jag kanske skall säga det jag förvånar mig mest över är att av alla de böcker, artilare och projekt jag sett samt vart med i så har ingen byggt efter detta mönster även om det faksiskt är ett rätt bra mönster. Dock har de projekt jag vart med i varit projekt som levt ganska kort eller byggts om när ny teknik kommit så man har inte kunnat lägga en sådan god grund. Rätt synd faktiskt. Men nu när saker och ting lutar mer mot att man går utifrån in i designen kanske interfacen blir mer ett krav.

Jag borde kanske bygga mer interface för de delar som ligger utåt mellan de olika lagrerna.
Idag bygger jag ganska modulära biutar så vill jag exempelvis byta ut artikelhanteringen byter jag utt dess modul eller uppgraderar den typ. Arkitektur är så stprt så det går inte säga vad som är rätt eller fel, utan det är mer en smaksak samt något man måste basera på kraven och dess livslängd.

Mvh Johan

Jag kan bara komma med ett svar Johan, ett som du säkert inte kommer att tycka om :) Jag har upplevt samma sak som du i MS världen...man har inte där ännu hunnit inse fördelarna med interfacedriven utveckling och kanske är utbudet på olika komponenter inte lika stort om man jämför med Javas open source värld. I Javavärlden använder man det för fullt. Om man t ex vill plugga in en tredjepartskomponent så är det vansinne egentligen att programmera direkt mot det api:et. Api:et kan förändras eller kanske produkten läggs ner och man måste leta upp en annan. Har man då varit duktig :) och använt sig av interface är det bara att implementera interfacet med den nya tredjepartskomponenten och inte en kodrad i verksamhetskoden behöver förändras. Eller kan man också låta tredjepartsleverantörer implementera interfacet och ge valmöjligheter till kunden. I projektet jag arbetar med nu använder vi oss av Spring framework men det kan mycket möjligt bli så att vi vill nyttja EJB 3 när specen är färdig och har blivit implemetnerad. Ok att det kommer att bli en del omskrivningar men INTE i gränssnitten mellan de olika lagren. Spring har en väldigt trevlig IoC funktionalitet och AOP stöd som gör ramverket helt underbart att arbeta med. Om någon är nyfiken på Java så kolla in det på www.springframework.org.

Jag har en gyllene regel och det är att alltid programmera mot interface. Jag tror att ni alla gör det ganska mycket i den vanliga koden också. Ni returnerar t ex en List från en metod och inte en ArrayList, när ni instantierar en HashMap gör ni det med: Map map = new HashMap() osv.

/Nils

Ok. Java och MS värld skilljer sig dock lite. Det tråkiga är att man oftast enbart förlitar sig på MS APIer och komponenter för att man vet att de då kommer leva vidare, en slags dum trygghet. Det jag anser är dumt är just att andra parter inte kan komma in i bilden. MS är långt i från bäst, ok de har idéer vilket är bra men att binda sig till bara deras komponenter ger också begränsningar. Än idag har de inte lanserat ett O/R Mapping verktyg. De har få drivers för olika databaser m.m. man binds rätt mkt till just MS saker, det är ju vad de vill och det är ju inget fel på dem, jag nyttjar dem hela tiden för att de ökad den administrativa effektiviteten för dem i bla Vs .Net, 2005an kommer bli ännu trevligare dock är den bara i Beta1 och en Beta 2 kommer efter jul.

Pga detta har man heller inte behövt bygga med Interface, för att inte röra ihop det för andra så pratar jag inte grafiska element eller en klass utséende, utan Interfacen man specar hur en klass skall se ut som klasserna sedan ärver för att få ett krav vilka APIer de måste ha. (vet ej om jag fick till det där bra.) Dock kan man ju även se Interface som wrappers mellan de olika komponenterna och på så vis få ett bra stöd för utbyte av 3de parts komponenter som kanske dör ut. Jag brukar oftast om jag nyttjar en 3de part produkt bygga en liten facad mellan dem och mina lager för att lättare kunna byta ut dem.
Sedan brukar jag nyttja Interface eller abstrakta klasser för att öka det polymorfiska.

Men kraven att basera lösningarna på ett sånt sätt du beskriver är inte lika stort i MS värld som i Javas då man "oftast" nyttjar MS ramverk rakt av och vet att det kommer vara bakåtkopatibelt. Finns för och nackdelar med att göra på detta sätt och jag anser det inte vara felaktigt heller men man borde titta lite mer på 3de parters produkter också, för det finns många bra, väntar bla ivrigt på nHibernate.

Jag har läst många böcker på senare tid där de bara nyttjar Java som exempel men de har faktiskt inte beskrivit din modell i dem, De har klart nämt den men även en massa andra. Har du någon trevlig bok du kan rekommendera ang just dessa ting? Jag har mest riktat in mig på Fowler, Kent Beck, Eric Evans och några få till, men det finns ju flera duktiga tänkare som har helt andra åsikter än dessa. Dock har de fallit mig i smaken då de håller sig rätt nära hur jag tänker.

SOA där emot, är det något du jobbat med? eller jobbar med? Där baserar man ju allt från dess interface. Arg... tycker det är så dumt att de har samma ord för flera olika betydelser. Vad jag menar nu är själva APIerna utåt för tjänsterna. Detta sätter ju en del nya krav på arkitekturen där både Wrappers och Interface blir viktigare. Men detta är på en högre nivå än den skiktade. För en Service i sig har ju sina skikt. Dock blir ju en Service ett DAL skickt för den applikation som nyttjar dem. Vill inte spinna vidare på detta nu utifall tråden skapare läser detta då det kan skapa förvirring.

Mvh Johan

Det först en intresant diksussion ang Interface i en Java tråd. Om du/ni är mer nyfikna är det bara att ta en titt.

http://www.pellesoft.se/communicate/forum/view.aspx?msgid=147723&forumid=60&sum=0

Hej

Är IoC samma som AOP.

Nils, har du sett något ramverk för IoC till .net som är bra. Spring verkar inte utvecklas längre å pico verkar inte vara klart. Ha, såg att det finns massvis med godis klart i .net redan.

Skulle vara intressant att höra mer om dina erfarenheter med Ioc. Kanske en artikel :)

Walle:

Nej, IoC eller Dependency Injection som det också kallas är inte samma sak som AOP...långt därifrån...för långt för att beskriva här :)

Du skrev att Spring inte verkar utvecklas längre...du menar för .net då...jag vet faktiskt inte status för Spring och .Net. Jag har tyvärr inte tittat på Pico för .Net så jag har inte så mycket att säga där heller. Men vad jag kan säga är att de fungerar alldeles utmärkt på javaplattformen.

/Nils

Ok

Yepp, menade .net. En del intressant diskussioner på deras mailinglista med det verkar inte hända mycket med koden (som inte finns än) Pico sägs fungerar, men jag får inte kläm på det. Det snacks rätt mycket om Aop å jag har aldrig fått tid till att sätta mig in i vad det är och vad nyttan är med det. Har du några tips på böcker som kan vara intressanta.. kvittar om det är för java eller .net.

Java verkar ha en massa roligt godis för utvecklarna..

Walle,

"Java verkar ha en massa godis..."

Så sant så, fördelen är mer den politiska kultur Java har som inte MS ännu har. Där man förlitar sig på andras verk och idéer, i MS värld är det lätt hänt att man _Bara_ förlitar sig på det MS säger eller ger ut. På så vis ligger många MS utvecklare efter (tyvärr) då de oftast inte kommer i kontakt med andra saker. En stror anledning varför MS inte går ut så mkt med andra ramverk och arkitketurer än den de själva förespråkar beror troligen mycket på att de inte har tid att skriva om allt och då tar de saker de själva brinner för. I Javas värld blir man inte lika fastlåst vid en teknisk lösning då det inte direkt finns en Aktör som är stor. SUN går ju ut med en del idéer m.m. men utvecklar dem inte så tungt (som jag känt det) och på så vis får andra tänkare plats i bilden. Jag har fått känslan att MS förstått detta och troligen även ser det som ett litet problem. De börjar mer och mer tala öppet om andra lösningar. Då erfarenheten hos många MS utvecklare inte är så stor som i Javas värld, förlitar man sig fortfarande för mycket på vad MS anser om de olika lösningar som finns. De kan inte riktigt ta egna beslut då de inte har så bra koll på de olika sakerna. jag har mina Idéer, Nils sina du har dina, Foweler sina, Larman sina, Evans sin etc... Och jag anser att ingen av dem eller oss gör något direkt fel, allt handlar om smaksak, men det är Absolut inte fel och läsa samt lyssna på vad de olika säger för att bilda sin idé. Att blint förlita sig på en aktör eller en författare är kanske lite synd. Som med politiken, innan man kan ta en ställning bör man ta reda på vad de olika aprtierna vill innom alla områden vad deras mål är och vad de tror de kan göra för sverige och därefter göra ett val vad man själv tror på, inte vad andra tror på.

Jag och min bror arbetar på att snart få upp vårat forum Nsquared2 där vi kommer prata om oliak saker kring utveckling, vi arbetar just nu på att få till ett intressant gäng som vi kan binda oss samman med för att sprida kunskaperna så Vi inte låser fast oss vid vad vi tycker. Jag vill inte säga för mkt just nu men forumet kommer bli lite annorlunda än de vanliga traditionella. Alla kommer vara välkomna att skriva eller prata om saker de själva står för, och vi hoppas att det kommer bli en stor spridning av idéer och tankar kring det som publiceras. Vi kommer bla ta upp många gosaker som finns i Javas värld idag för att föra in dem mer o mer in i .Net världen. Mkt är på gång i om version 2 av ramverket där du faktiskt kommer få se en del gosaker som man tagit med sig.

Mvh Johan

Walle, du skrev att du ville en förklaring kring Dependency Injection...jag svarade att jag inte orkade...men man är ju inte bättre än att man kan ändra sig ;) La en liten post under Systemutveckling generellt (http://www.pellesoft.se/communicate/forum/view.aspx?msgid=148270&forumid=81&sum=0). Håll till godo och hör av dig om det är något du inte förstår eller tycker är oklart.

/Nils

Johan, du har i stort rätt i det du skriver men en liten detalj vill jag poängtera. Du skrev

"I Javas värld blir man inte lika fastlåst vid en teknisk lösning då det inte direkt finns en Aktör som är stor. SUN går ju ut med en del idéer m.m. men utvecklar dem inte så tungt (som jag känt det) och på så vis får andra tänkare plats i bilden."

Du har rätt, man behöver inte bli fastlåst vid en teknisk lösning...så länge man programmerar mot interface ;) Och på ämnet tunga aktörer så skulle jag vilja säga att Sun är en väldigt tung aktör. Förutom att driva utvecklingen av språket framåt så är de också, tillsammans med företag och privatpersoner, skapare av Javas motsvarighet till .NET...nämligen J2EE. Sun, med partners, tar fram specen och sedan är det upp till vem som helst att implementera specen och J2EE-certifiera sin appserver. Exempel på sådana appservrar är WebLogic (Bea), WebSphere (IBM), JBoss (Open Source), Orion Server (IronFlare), Jonas (Open Source) osv. Detta gör att man kan skriva en applikation enligt spec (J2EE) men köra den på vilken appserver som helst utan att, i stort sett, behöva göra några förändringar. Detta gör att man kan välja vilken implementation man vill...den som passar ens behov bäst. DET är en stor fördel. J2EE specen är egentligen bara en massa interface och regler för hur dessa ska implementeras...ständigt dessa underbara interface ;) En del tycker att J2EE specen kan vara lite krånglig och komplex och det är därför mindre ramverk som t ex Spring framework vuxit upp.

Men tillbaka till stor aktör...Sun är än så länge en väldigt stor aktör.

/Nils

Nils,

Ang aktör så menar jag inte som företag utan mer som Arkitket tryckare, de binder en inte lika hårt till dess produkter så som MS ramverk gör idag, tack vare sitt mer fria och breda sätt att arbete. Det var mer så jag menade, vad jag vet uppmanar väl SUN till 3de parts produkter? det gör inte MS på samma sätt. Har SUN byggt eget jUnit ramvetk så som MS gjort till 2005? eller kör bakar de in 3de aktörers saker i deras IDE apps?

En liten poäng, det är många som tror att .net är en motsvarighet till J2EE men det är fel, J2EE är ju mer en spec inte ett ramverk fullt med specar. J2EE är nog mer motsvarat det MS hade (DNA) spec och idéer hur man bygger Enterprise lösningar. Där man då kan ta del av ramvek. Tycker själv det är lite rörigt, .Nets motsvarighet till J2EE skulle mer vara PAP (Patterns & Practisec) från MS PAG team. Där det specar hur de tycker en Enterpriselösning skall se ut med .Net i botten.

Skall läsa din text om Dependency Injection/Inversion of Control, verkar intressant.

mvh Johan

Johan, du har fel när du jämför J2EE och Windows DNA. Men jag tänker inte gå in klinch med dig för att diskutera detta. Och det pga av följande logiska resonemang:

1. Alla som kan, har jobbat med, J2EE och läst specen vet att J2EE != Windows DNA

2. Johan, du har inte läst specen eller jobbat med J2EE

Slutledning: Johan kan inte veta om J2EE != Windows DNA eller om J2EE == Windows DNA och diskussionen blir därför lite onödig ;)

Observera nu smileyn ;)

/Nils

Nils,

vet, men skrev är nog mer motsvarigheten för DNA (alltså inte ser ut som DNS, men just en spec över enterprise lösningar med de produkter som finnsa tillhanda m.m.) alltså mer likt DNA än .Net då .Net inte är en spec. typ... Jaja skit samma.

Har läst lite om J2EE, men som du säger inte alls mkt. Men pratat med andra som bygger efter dess modell.

Nana dags, ha det... han inte läsa din artikel, såg AvP den var ok. Älskar Alines, hoppas de gör någon film hur de kom till eller vart de kom från någon gång... God natt..

Mvh Johan

Såvitt jag förstått från Rod Johnson (som är en av personerna bakom Spring) för någon vecka sedan eller så så bygger de vidare på Spring för .NET.

Rod kommer förresten nästan till Sverige i september. Han skall prata på JAOO (www.jaoo.dk) i Århus.

Mvh
Jimmy
www.jnsk.se/weblog/
###

Hej Nils å tack..

Var egentligen mest intresserad av dina erfarenheter av det.. Men tack igen..

Vad menar duWalle? Hur jag använder IoC? Hur jag använder AOP?

/Nils

Jag ska försöka förklara det här med J2EE Johan så att du inte längre behöver jämföra J2EE med Win DNA...och sedan kan vi, som du skrev, "skita i det" :) ...som jämörelse använder jag .NET.

1. J2EE är en spec som skrivs av Sun. - .NET specas av Microsoft

2. J2EE specen implementeras av de aktörer, t ex IBM, Oracle, Bea, som vill implementera den - .NET implementeras bara av Microsoft, det är ingen öppen spec på det sätt som J2EE

3. Resultatet av t ex Beas J2EE implementation är en appserver som är J2EE certifierad - Resultatet av Microsofts implementation av sin egen spec är .NET ramverket

Beas implementation innehåller bla jsp, servlets, jms (meddelandehantering), jta (transaktionshantering), rmi (remote method invocation), WebServices mm. Detta innehåll finns också IBM's implementation, Oracles osv. Detta är klart att använda för alla utvecklare. Liknande teknologier finns i .NET ramverket som t ex asp, transaktionshantering mm.

Så att jämföra J2EE med .NET kanske blir fel eftersom man då jämför en specifikation av ett ramverk med ett implementerat ramverk. Bättre är kanske att då säga att man jämför en J2EE certifierad appserver med .NET ramverket...och de är helt klart jämförbara och jämnbördiga vad gäller funktionalitet mm. Men det är enklare att prata generellt om J2EE än att prata om specifika implementationer så jag fortsätter med det.

Hoppas att allt blir klarare nu

/Nils

Jaha, ok. Jo nuj klanar det mer. Har dock läst lite om J2EE där de flera ggr påpekat att det inte går att jämföra J2EE med .Net, då J2EE var mer en spec över enterprise lösning (hur man med vissa byggstenas skapar en god enterprise arkitektur), vilket DNA gör fast med sin funktions orienterande teknik.
Dock så varierar många artiklar om just J2EE vs .Net där även SUN sa en hel del fel saker om .Net i sin motsvarande artikel som kom 2000. Men det du säger låter faktiskt mer rimmligt när jag tänker efter.

När vi ändå pratar arkitektur och skikt, så är jag lite nyfiken vad du anser om SOA.

Mvh Johan

Vi kanske skulle starta en ny tråd om vi ska diskutera SOA? Känns som om det inte riktigt hör hemma i den här tråden...börjar bli lite överfyllt.

/Nils