[.NET] applicatie integratie, wie heeft er tips ?

maandag 10 januari 2005 20:15

Allereerst:
zorgen voor een goede communicatie tussen de teams
zorg ervoor dat ieder team weet wat er van hen verlangd wordt
zorg voor een standaard/library, zodanig dat je een uniforme UI krijgt
zorg ervoor dat het project zo opgezet is dat het systeem makkelijk uitbreidbaar is
zorg voor een goede testomgeving (unit testing, integration testing, performance testing)
etc...

https://fgheysels.github.io/

Acties:

Verwijderd

Hmmm,

Wel een groot project. Als alles mooi multi tier is opgezet zou je bijvoorbeeld een schil over alle verschillende business objects kunnen bouwen, die kan je dan mooi bijvoorbeeld d.m.v. web services open zetten. Je zou ook met reflection aan de slag kunnen gaan om op die manier opdrachten uit te voeren over andere assembly's, maar dat lijkt mij niet echt aan te raden (nogal traag). Er blijft volgens mij altijd een heleboel werk aan zitten, tenzij het een web applicatie is en je gewoon leuk naar andere pagina's kan linken... dan is de integratie redelijk snel te doen. Ik heb wel voorbeelden voor een "single sign on" systeem dat je dan kan gebruiken zodat je maar 1 maal hoeft aan te melden en dat dit dan door wordt gegeven naar je overige web applicaties.

Ik zou met zo'n groot pakket wel een beter source management pakket gebruiken dan sourcesafe, mijn ervaring met Perforce is erg goed, die integreert ook perfect in Visual studio .NET.

Succes in elk geval!

[ Voor 34% gewijzigd door Verwijderd op 10-01-2005 20:18 ]

maandag 10 januari 2005 21:01

Acties:

maandag 10 januari 2005 22:14

Verwijderd schreef op maandag 10 januari 2005 @ 20:15:

Wel een groot project. Als alles mooi multi tier is opgezet zou je bijvoorbeeld een schil over alle verschillende business objects kunnen bouwen, die kan je dan mooi bijvoorbeeld d.m.v. web services open zetten. Je zou ook met reflection aan de slag kunnen gaan om op die manier opdrachten uit te voeren over andere assembly's, maar dat lijkt mij niet echt aan te raden (nogal traag). Er blijft volgens mij altijd een heleboel werk aan zitten, tenzij het een web applicatie is en je gewoon leuk naar andere pagina's kan linken... dan is de integratie redelijk snel te doen. Ik heb wel voorbeelden voor een "single sign on" systeem dat je dan kan gebruiken zodat je maar 1 maal hoeft aan te melden en dat dit dan door wordt gegeven naar je overige web applicaties.

Ik vind dat je hier nogal wat aannames doet, en met buzz-words gooit zonder dat je weet wat de scope van het project is?
Zijn webservices wel nodig ? Zou het wel nodig zijn om via reflection andere assemblies te gaan benaderen ? Etc...

Ik zou met zo'n groot pakket wel een beter source management pakket gebruiken dan sourcesafe, mijn ervaring met Perforce is erg goed, die integreert ook perfect in Visual studio .NET.

Wat is er mis met SourceSafe (behalve dan dat het een oud systeem is, en met een obscuur custom data-base werkt )?
Ik heb al altijd VSS gebruikt, en nog nooit grote problemen gehad.
Als je idd geen VSS wilt gebruiken, kan je ook eens naar SourceGear's Vault kijken. Ik heb het eens vluchtig bekeken, en het ziet er wel goed uit.

Maar goed, mijn mening is dat je niet eerst naar de technieken/technologieën moet kijken maar naar de organisatie van het project en hoe je de communicatie tussen de projectteams gaat aanpakken.

https://fgheysels.github.io/

Acties:

maandag 10 januari 2005 22:39

Topicstarter

Verwijderd schreef op maandag 10 januari 2005 @ 20:15:
Hmmm,

Wel een groot project. Als alles mooi multi tier is opgezet zou je bijvoorbeeld een schil over alle verschillende business objects kunnen bouwen, die kan je dan mooi bijvoorbeeld d.m.v. web services open zetten.<>knip

Binnen elke fysieke eenheid (de assembly) is een logische applicatie architectuur voor ogen met een knipoog naar Microsoft 's DNA structuur (UI, Bus, Data laag, met binnen elke laag een differentiatie naar gelang dat nodig is, bijv. business entities, data access logic comp.)

Ik moet er wel bij vermelden dat de applicaties niet als basis webservices kan hebben omdat IIS niet in de deployment zit, anders was ik er natuurlijk al lang uitgekomen ;-)

Ik had gedacht om elk subsysteem naar een assembly te laten compileren. Elk subsysteem bestaat uit een aantal use cases. Elke use case wordt gezien als functionaliteit dat aangeroepen kan worden door elke applicatie binnen het totale framework. Nu had ik een ModelViewControllerSDK geschreven om elke use case een Model, View en Controller te geven. Dit geheel van elke use case (met een MVC setje) wordt als plugin gestart (dus de plugin maakt het model, maakt de view en controller en knoopt het geheel aan elkaar).

De vorige alinea bevat voornamelijk de oplossingsrichting binnen in een applicatie zelf. Het grootste probleem zit 'm in de inter applicatie communicatie. Als ik gebruik wil maken van functionaliteit van een andere assembly (lees: een use case uit de assembly) dan wil ik zo weinig mogelijk kruisverwijzingen hebben; dus bij de load van een assembly om een use case te starten hoeven dan niet tig andere assemblies geladen te worden.

IT-architect zijn blijft een leuk vak ;-) !

Acties:

maandag 10 januari 2005 22:56

-= Tja =-

Is het project al aan de gang? Of moet er nog aan begonnen worden? Dus is het een kwestie om bestaande functionaliteit er uniform uit te laten zien? Of kan helemaal from scratch begonnen worden?

En verder.. wat versta je onder uniformiteit? Dat overal de zelfde 'look and feel' wordt gebruikt? Of dat er een grotere lijn in het dit grote product zit? Het lijkt me verder dat als zo`n product een beetje tot een goed einde gebracht moet worden, dat er ook een bepaalde visie is die verkondigt kan worden. En ook de mogelijkheid om de architectuur die hoort bij die visie de leidraad te laten vormen en die leidraad te kunnen volgen en eventueel af te dwingen.

Versioning ed vind ik minder belangrijk dan een goeie technische leidraad in het project. Maarja.. ik heb ook geen ervaring met dit soort projecten en mijn kennis is voornamelijk theoretische van aard. Ik zou in ieder geval oppassen met allerlei details en zorgen dat de architectuur van het systeem goed wordt uigedacht.

[edit]
En webservices zijn imho redelijk detail geneuzel. Je maakt een bepaalde interface remote en welk stuk middleware je daar nou voor kiest zou in principe niet al te veel invloed moeten hebben -> dus geen bijster interessant onderwerp mbt de architectuur.

[ Voor 21% gewijzigd door Alarmnummer op 10-01-2005 22:48 ]

Acties:

Verwijderd

Ik moet er wel bij vermelden dat de applicaties niet als basis webservices kan hebben omdat IIS niet in de deployment zit, anders was ik er natuurlijk al lang uitgekomen ;-)

WebServices onder .NET betekent niet automatisch IIS hoor.

Kijk 's naar Indy, een open source project voor zo ongeveer alles wat je maar kunt verzinnen op internet/intranet gebied.

Een tijd terug heb ik een gedrocht van een webservice (IIS, C# frontend en Delphi COM library voor de business logic) in een paar uur kunnen omzetten naar een stand-alone webservice die geen andere dingen nodig had om te deployen.
't Is wel een Delphi webservice geworden (daar ben ik ervarener in, de business logic was daarin geschreven, en er was nog geen .NET versie van Indy), maar die Indy jongens weten wel hoe 't moet.

Die webservice draait nu bij een leuk aantal hotelketens om web-reserveringen te verwerken, en qua performance en stabiliteit heb ik niks te klagen. Kortom, ga 's kijken naar Indy!

dinsdag 11 januari 2005 08:46

Acties:

dinsdag 11 januari 2005 15:39

-= Tja =-

DrDelete schreef op maandag 10 januari 2005 @ 19:44:
Stel:
Moet je werken met interfaces ?

Wat is dat nu voor een gekke vraag?

En verder moeten jullie wel goeie contracten opstellen waarmee de systemen met elkaar kunnen communiceren. Persoonlijk doe ik dat het liefste met interfaces.. Maar dit zal het bij jullie verder gaan dan alleen een paar interfaces op te stellen.

Moet er een broker komen ?

Je krijgt een Broker als je een client een server wilt laten gebruiken als je een volledige ontkoppeling wil van de taal/locatie van die server. De broker is dan de middleman die die client met een gewenste server in contact brengt + het eventuele verschil in talen wegwerkt.

De vraag is of jij dit nodig bent, want je hebt niet duidelijk gemaakt welke communicatie er moet komen. Mogen er stukken asynchrone communicatie in bv? (Asynchrone communicatie heeft erg veel voordelen.. ) Als het .net/.net is, waarom in godsnaam dan XML-webservices voor communicatie? Ik zou dus absoluut niet weten wat jij nodig bent voor je project en dan kan iedereen wel dingen roepen... maar dat is imho volslagen zinloos.

Als je trouwens een goed boek wilt lezen over software architectuur wilt lezen waarin oa de Broker aan bod komt, adviseer ik je : Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Een geweldig boek waarin patterns op een hoger nivo aan bod komen.

En als je een goed boek over asynchrone communicatie wilt lezen, dan raad ik je deze aan: Enterprise Integration Patterns : Designing, Building, and Deploying Messaging Solutions

[ Voor 25% gewijzigd door Alarmnummer op 11-01-2005 08:52 ]

Acties:

Verwijderd

Je zegt dat het voor de klant gelijk moet ogen. Wat de klant ziet is de GUI (of zijn er no andere dingen ? Indien ja, de GUI blijft het belangrijkste punt, je ziet direct als het door verschillende teams ontworpen is ...) Zet 1 team op de GUI (deel dus je 80 mensen in 6 teams in), op deze manier zal de GUI gelijk ogen. Gebruik MVC concept, naar mijn mening zou dit ideaal werken.

Je zal dus in de GUI alleen calls zoals dit hebben :

C#:

private void btnSave_Click()
{
   Controller.SavePerson(txtName.Text, txtFirstname.Text);
}

De 'retour' gebeurd met events vanuit de controller

Tip : Steek wel mensen op de GUI die het heel graag doen, want het zal vrij saai werk zijn voor mensen die liever code kloppen.

[ Voor 10% gewijzigd door Verwijderd op 11-01-2005 15:40 ]

dinsdag 11 januari 2005 15:40

Acties:

dinsdag 11 januari 2005 16:01

Alarmnummer schreef op dinsdag 11 januari 2005 @ 08:46:
[...]

Als je trouwens een goed boek wilt lezen over software architectuur wilt lezen waarin oa de Broker aan bod komt, adviseer ik je : Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. Een geweldig boek waarin patterns op een hoger nivo aan bod komen.

Ik moet deze nog eens ergens vandaan zien te halen...

https://fgheysels.github.io/

Acties:

dinsdag 11 januari 2005 16:13

-= Tja =-

Verwijderd schreef op dinsdag 11 januari 2005 @ 15:39:
Je zegt dat het voor de klant gelijk moet ogen. Wat de klant ziet is de GUI (of zijn er no andere dingen ? Indien ja, de GUI blijft het belangrijkste punt, je ziet direct als het door verschillende teams ontworpen is ...) Zet 1 team op de GUI (deel dus je 80 mensen in 6 teams in), op deze manier zal de GUI gelijk ogen. Gebruik MVC concept, naar mijn mening zou dit ideaal werken.

Wat is dat nou voor onzin??? Waarom zou je bij een ontkoppeling van model en view ineens een consistente gui moeten krijgen???

Acties:

dinsdag 11 januari 2005 16:17

Alarmnummer schreef op dinsdag 11 januari 2005 @ 16:01:
[...]

Wat is dat nou voor onzin??? Waarom zou je bij een ontkoppeling van model en view ineens een consistente gui moeten krijgen???

Dat zegt hij toch niet?
Hij zegt: zet 1 team op de GUI, zo kan je een consistente gui krijgen. Op die manier heb je geen 2 teams die elk een afzonderlijk idee hebben wb de GUI.

https://fgheysels.github.io/

Acties:

dinsdag 11 januari 2005 17:03

-= Tja =-

whoami schreef op dinsdag 11 januari 2005 @ 16:13:
[...]

Dat zegt hij toch niet?
Hij zegt: zet 1 team op de GUI, zo kan je een consistente gui krijgen. Op die manier heb je geen 2 teams die elk een afzonderlijk idee hebben wb de GUI.

*Wrijft de stront ff uit zijn ogen*... idd.. Maar om een bedrijf nou maar op de gui te zetten (als die er is) en een ander bedrijf alleen op de achterliggende code is wel erg horizontaal gedacht. (En ik vraag me daarom ook af hoe verstandig dit nu is)

[ Voor 23% gewijzigd door Alarmnummer op 11-01-2005 16:18 ]

Acties:

Verwijderd

Hij spreekt niet van een bedrijf. De poster spreekt van 80 man verdeeld in 5 teams. Dus alles binnen 1 bedrijf.

Waarom dan niet onderverdelen in 6 teams waarvan 1 team het volledige GUI gedeelte kan doen ? Zo ben je zeker van consistentie in de GUI, wat het meest opvallende is naar de klant toe. Het valt direct op als het door verschillende teams gedaan wordt.

MVC omdat de GUI-mannen dan praktisch niks moeten weten van het onderliggende, en de ontwikkelaars geen GUI nodig hebben om hun stuk te testen.

Misschien de stront uit het andere oog ook wrijven ?

dinsdag 11 januari 2005 17:27

Acties:

dinsdag 11 januari 2005 17:34

Topicstarter

Verwijderd schreef op maandag 10 januari 2005 @ 22:56:
[...]

WebServices onder .NET betekent niet automatisch IIS hoor.
Kijk 's naar Indy, een open source project voor zo ongeveer alles wat je maar kunt verzinnen op internet/intranet gebied.

Ik heb even gekeken maar leg mij eens uit hoe ik een webservice - mbv Indy components - zonder IIS kan draaien...

Acties:

dinsdag 11 januari 2005 17:40

Topicstarter

Verwijderd schreef op dinsdag 11 januari 2005 @ 15:39:
Je zegt dat het voor de klant gelijk moet ogen. Wat de klant ziet is de GUI (of zijn er no andere dingen ? Indien ja, de GUI blijft het belangrijkste punt, je ziet direct als het door verschillende teams ontworpen is ...) Zet 1 team op de GUI (deel dus je 80 mensen in 6 teams in), op deze manier zal de GUI gelijk ogen. Gebruik MVC concept, naar mijn mening zou dit ideaal werken.

Je hebt gelijk: voor alle teams moet er een soort .NET toolbox library komen met een set aan componenten die dezelfde look-and-feel kunnen realiseren. De scope van het opgevoerde probleem zit 'm daar ook niet in.

Ik zal 't probleem iets verder uitlichten:

1) Elk team heeft levert een set aan functionaliteiten op, zegge een set aan assemblies, geversioned en gesigned.
2) Elke assembly kan weer een referentie hebben naar functionaliteiten die a) door het projectteam zelf is ontworpen en waar dat projectteam ook grip op heeft en b) door andere teams is opgeleverd waarbij de gereleasde set van assemblies als file references gebruikt wordt

De release manager wilt assemblies kunnen bouwen in een night-build en daarnaast willen ontwikkelaars alleen die .csproj projecten in hun .NET solution hebben waarmee ze de build zonder problemen mee kunnen bouwen. Moet elk projectteam altijd dan werken met de latest build ? of moet elk projectteam werken met assemblies die officieel zijn gereleased door de release manager. Dit alles heeft impact op de structuur in sourcesafe en daarmee bepaalt het ook de .NET solution structuur. Misschien is een scenario denkbaar waarbij elke ontwikkelaar de vrijheid wordt gegeven om zelf de .csproj items er maar bij te halen in een zelf gemaakt .NET solution... wat is wijsheid ?

Acties:

dinsdag 11 januari 2005 17:42

-= Tja =-

Nogmaals.. is het niet een stuk belangrijker om een bepaalde technische lijn in dit product te krijgen? Ipv dat iedereen maar een beetje als cowboy van alles zelf gaat bedenken. Is er bv al een architectuur uitgedacht?

Acties:

dinsdag 11 januari 2005 18:43

Topicstarter

Alarmnummer schreef op dinsdag 11 januari 2005 @ 17:40:
Nogmaals.. is het niet een stuk belangrijker om een bepaalde technische lijn in dit product te krijgen? Ipv dat iedereen maar een beetje als cowboy van alles zelf gaat bedenken. Is er bv al een architectuur uitgedacht?

dit is toch onderdeel van de 'techniche lijn'. Als je er anders over denkt, moet je hier definiëren wat je onder 'technische lijn' verstaat

Acties:

dinsdag 11 januari 2005 20:06

DrDelete schreef op dinsdag 11 januari 2005 @ 17:34:
De release manager wilt assemblies kunnen bouwen in een night-build en daarnaast willen ontwikkelaars alleen die .csproj projecten in hun .NET solution hebben waarmee ze de build zonder problemen mee kunnen bouwen.

Nee, ontwikkelaars moeten alleen DIE csproj projecten in hun solution hebben waar ze source van wijzigen. Alle andere projecten moeten in assembly vorm worden gereferenced. Anders krijg je een mega solution waar je echt niet mee wilt werken.

Moet elk projectteam altijd dan werken met de latest build ? of moet elk projectteam werken met assemblies die officieel zijn gereleased door de release manager. Dit alles heeft impact op de structuur in sourcesafe en daarmee bepaalt het ook de .NET solution structuur.

Dat laatste lijkt me onzin. Je project werkt met verschillende blokken, waar verschillende teams aan werken. Ieder blokje is eigendom van een team (of subteam) en bepaalt welke versie de laatste is en welke versie de nieuwe wordt. Dit heeft niets met de structuur in je sourcecontrol systeem te maken (zou geen sourcesafe kiezen met zoveel ontwikkelaars), als in: welke build gebruikt wordt zorgt voor een structuuraanpassing, maar heeft wel invloed op hoe je je project opdeelt in verschillende onderdelen.

Ieder projectteam werkt met de assemblies van andere teams zoals deze zijn opgeleverd door die teams. Komt er een update van een van de assemblies, dan moet de eigenaar van die assembly dat vertellen aan de gebruikers van de assembly en die moeten dan eventueel migratie werkzaamheden uitvoeren. Zodoende krijg je ook spreiding van wie is waar verantwoordelijk voor, want dat raakt gauw zoek in een multi-team opzet.

Let er op dat gesignde assemblies een vooraf gedefineerde versioncodering krijgen. Anders krijg je bij iedere build een andere versie en moet je alles recompilen telkens. Per team is het zaak de interfaces EERST op te zetten, DAN die te 'stubben' en dan die te implementeren. Zodoende krijg je snel een werkbare assembly voor de andere teams zonder dat je telkens interfaces moet veranderen.

Misschien is een scenario denkbaar waarbij elke ontwikkelaar de vrijheid wordt gegeven om zelf de .csproj items er maar bij te halen in een zelf gemaakt .NET solution... wat is wijsheid ?

Dat lijkt me de grootst mogelijke ellende opleveren. Dit soort grote projects is het zaak alles strict volgens regels te doen anders krijg je chaos.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

dinsdag 11 januari 2005 20:46

-= Tja =-

DrDelete schreef op dinsdag 11 januari 2005 @ 17:42:
[...]
dit is toch onderdeel van de 'techniche lijn'. Als je er anders over denkt, moet je hier definiëren wat je onder 'technische lijn' verstaat

Ik drukte me wat ongelukkig uit. Maar je hebt nog steeds geen antwoord op de vraag gegeven. Is er al een architectuur uitbedacht voor dit (in mijn ogen) megaproject.

Ik maak uit jouw antwoorden op dat er dus geen overkoepelende architectuur is. Iedereen die maakt zijn onderdeel maar ik heb er geen gemeenschappelijke gedachte in kunnen ontdekken. Het enigste gemeenschappelijke waar jij mee aan komt zetten zijn oa assemblies/versioning. Ik zie nog wel een kreet voorbij komen als Broker, ik heb mijn commentaar daarop gelevert en verder nog niets van jouw kant terug gehoord.

[ Voor 38% gewijzigd door Alarmnummer op 11-01-2005 20:12 ]

Acties:

dinsdag 11 januari 2005 21:00

Ik ben het eens met Alarmnummer, wat heb je al qua architectuur ?
Kan je het project opsplitsen in verschillende subprojecten die technisch gezien niets of niet veel met elkaar te maken hebben ?
Kan je het project makkelijk opsplitsen in 5 subsystemen?

https://fgheysels.github.io/

Acties:

dinsdag 11 januari 2005 21:07

Topicstarter

Nee, ontwikkelaars moeten alleen DIE csproj projecten in hun solution hebben waar ze source van wijzigen. Alle andere projecten moeten in assembly vorm worden gereferenced. Anders krijg je een mega solution waar je echt niet mee wilt werken.

Waarom geen mega solution. Je kunt toch per ontwikkelaar een eigen configuration maken door alleen die assemblies aan te vinken in de configuration manager die je nodig hebt ? De master solution blijft dan bruikbaar voor de night-build.

Dat laatste lijkt me onzin. Je project werkt met verschillende blokken, waar verschillende teams aan werken. Ieder blokje is eigendom van een team (of subteam) en bepaalt welke versie de laatste is en welke versie de nieuwe wordt. Dit heeft niets met de structuur in je sourcecontrol systeem te maken (zou geen sourcesafe kiezen met zoveel ontwikkelaars), als in: welke build gebruikt wordt zorgt voor een structuuraanpassing, maar heeft wel invloed op hoe je je project opdeelt in verschillende onderdelen.

Wat is een "blokje". Is dat een set van .csproj's in een eigen solution ? Het kan namelijk zijn dat er een stuk functionaliteit gemaakt dient te worden waarbij je een nieuwe .csproj aanmaakt en andere .csproj's nodig hebt om daarbinnen sources aan te passen. Moet de overige functionaliteit (lees: assemblies) dan als file-references gebruikt worden (die assemblies die geen wijzigingen moeten hebben) ?

Ieder projectteam werkt met de assemblies van andere teams zoals deze zijn opgeleverd door die teams. Komt er een update van een van de assemblies, dan moet de eigenaar van die assembly dat vertellen aan de gebruikers van de assembly en die moeten dan eventueel migratie werkzaamheden uitvoeren. Zodoende krijg je ook spreiding van wie is waar verantwoordelijk voor, want dat raakt gauw zoek in een multi-team opzet.

Helemaal mee eens: maar wat doe je als er een lange release ronde is; dan bouw je misschien op functionaliteit die in de tussenliggende periode drastisch gewijzigd is; misschien wil je dan toch bouwen op night-build assemblies... Hoe los je dat op dan, beheers-technisch ?

Let er op dat gesignde assemblies een vooraf gedefineerde versioncodering krijgen. Anders krijg je bij iedere build een andere versie en moet je alles recompilen telkens. Per team is het zaak de interfaces EERST op te zetten, DAN die te 'stubben' en dan die te implementeren. Zodoende krijg je snel een werkbare assembly voor de andere teams zonder dat je telkens interfaces moet veranderen.

Goed idee, was ik ook van plan, maar... moeten interfaces dan in aparte assemblies ? Stel je hebt functionaliteitA.dll moet er dan een functionaliteitA.Interfaces.dll komen ?
[...]

Acties:

dinsdag 11 januari 2005 21:12

Topicstarter

Ik drukte me wat ongelukkig uit. Maar je hebt nog steeds geen antwoord op de vraag gegeven. Is er al een architectuur uitbedacht voor dit (in mijn ogen) megaproject.

Er is een logische (conceptuele) architectuur bedacht. Echter.. de technische applicatie architectuur laat nogal te wensen over. Zo is er nog geen coding guidelines, geen FxCop, geen NUnit, geen verplichte folder structuur onder elke .csproj (bijv. met 3 lagen en wat differentatie daarbinnen bijv.). Zodoende kan ieder project op zijn eigen manier zijn assmblies zo inrichten dat er uiteindelijk de assembly mee gemaakt kan worden, alleen is er geen overall structuur voor elke assembly bedacht; de vraag is ook of je elk .csproj in dezelfde keurslijf kunt gieten.

Ik maak uit jouw antwoorden op dat er dus geen overkoepelende architectuur is. Iedereen die maakt zijn onderdeel maar ik heb er geen gemeenschappelijke gedachte in kunnen ontdekken. Het enigste gemeenschappelijke waar jij mee aan komt zetten zijn oa assemblies/versioning. Ik zie nog wel een kreet voorbij komen als Broker, ik heb mijn commentaar daarop gelevert en verder nog niets van jouw kant terug gehoord.

Je kunt met een message broker onafhankelijk met verschillende assemlies communiceren door te serialiseren, echter dat heeft weer licentietechnische gevolgen, het mag natuurlijk niet veel kosten, dus dat is waarschijnlijk geen optie, maar ik noemde zodat er misschien wat ervaringen geplaatst zouden worden...;)

Acties:

dinsdag 11 januari 2005 21:17

-= Tja =-

DrDelete schreef op dinsdag 11 januari 2005 @ 21:07:
[...]
Er is een logische (conceptuele) architectuur bedacht.

Daar zijn we in geinteresseerd..

Je kunt met een message broker onafhankelijk met verschillende assemlies communiceren door te serialiseren, echter dat heeft weer licentietechnische gevolgen, het mag natuurlijk niet veel kosten, dus dat is waarschijnlijk geen optie, maar ik noemde zodat er misschien wat ervaringen geplaatst zouden worden...;)

Ik ken de Broker niet in de .NET context. Alleen de algemen zoals je oa aantreft bij Corba.

Acties:

woensdag 12 januari 2005 09:37

Topicstarter

whoami schreef op dinsdag 11 januari 2005 @ 20:46:
Ik ben het eens met Alarmnummer, wat heb je al qua architectuur ?
Kan je het project opsplitsen in verschillende subprojecten die technisch gezien niets of niet veel met elkaar te maken hebben ?
Kan je het project makkelijk opsplitsen in 5 subsystemen?

Je kunt "afgebakende functionaliteit" of subsystemen (what's in the name) classificeren:

1) utilities: oftewel libraries die geen verwantschap hebben met andere libraries en op zichzelf staan, zoals wiskundige routines, etc.etc.
2) mini subsystemen: deze assemblies bieden functionaliteit die door verschillende projecten hergebruikt worden én waar een user interface aan vast zit en waar een geringe mate van onderlinge assembly afhankelijkheid in zit (deze subsystemen hebben voornamelijk referenties naar de 1e categorie assemblies)
3) specifieke subsystemen: deze assemblies hebben gerichte/specifieke functionaliteit die niet herbruikbaar is door andere projecten, maar deze categorie maakt wel weer gebruik van categorie 1) en 2) assemblies.

Ik vond het zelf niet verstandig om de onderlinge references te laten terugzien in sourcesafe, maar dit te laten uitkomen in een solution waarbinnen je project en/of file references terugziet. Deze is dan ook te labelen bij een night-build. Hoe denken jullie hierover ?

Acties:

woensdag 12 januari 2005 09:44

DrDelete schreef op dinsdag 11 januari 2005 @ 21:00:
[...]
Waarom geen mega solution. Je kunt toch per ontwikkelaar een eigen configuration maken door alleen die assemblies aan te vinken in de configuration manager die je nodig hebt ? De master solution blijft dan bruikbaar voor de night-build.

Wat is de 'configuration manager' ? Je doelt toch hopelijk niet op de build config manager, want die gaat daar niet over. Als jij 20 projects in een solution stopt en die projects zijn wat groter dan de huis-tuin-keuken prutsels dan gaat vs.net vrolijk op zn muil in random situaties. Daar mag jij natuurlijk op kicken, ik heb geen idee, maar jouw developers zeker niet.

Wat is een "blokje". Is dat een set van .csproj's in een eigen solution ? Het kan namelijk zijn dat er een stuk functionaliteit gemaakt dient te worden waarbij je een nieuwe .csproj aanmaakt en andere .csproj's nodig hebt om daarbinnen sources aan te passen. Moet de overige functionaliteit (lees: assemblies) dan als file-references gebruikt worden (die assemblies die geen wijzigingen moeten hebben) ?

in vs.net is het zo project == assembly. Dus je bepaalt eerst hoe je gaat deployen, dwz ga ik alles in 1 assembly stoppen of in 2 of meerdere, dan per assembly een project aanmaken.

En dat doe je VER NADAT je de functionaliteit hebt ontworpen. Of ga je alles agile/XP achtig benaderen?

Helemaal mee eens: maar wat doe je als er een lange release ronde is; dan bouw je misschien op functionaliteit die in de tussenliggende periode drastisch gewijzigd is; misschien wil je dan toch bouwen op night-build assemblies... Hoe los je dat op dan, beheers-technisch ?

Je wilt niet voortbouwen op nightly builds. Daar heb je als ontwikkelaar van andere functionaliteit geen moer aan, je wilt voortbouwen op spul dat al een beetje werkt want anders ben je meer andermans spul aan het debuggen dan je eigen code. Dit houdt dus ook in dat niet alle 80 mensen direct aan de slag kunnen. Je moet eerst wat basiscode maken waar anderen mee verder kunnen.

Goed idee, was ik ook van plan, maar... moeten interfaces dan in aparte assemblies ? Stel je hebt functionaliteitA.dll moet er dan een functionaliteitA.Interfaces.dll komen ?
[...]

Een class heeft ook een interface. Het gaat erom dat team B software kan compileren tegen een assembly van team A, waarbij nog niet alle code in is geimplementeerd (dwz veel methods gooien nog een NotImplementedException())

DrDelete schreef op dinsdag 11 januari 2005 @ 21:07:
Er is een logische (conceptuele) architectuur bedacht. Echter.. de technische applicatie architectuur laat nogal te wensen over. Zo is er nog geen coding guidelines, geen FxCop, geen NUnit, geen verplichte folder structuur onder elke .csproj (bijv. met 3 lagen en wat differentatie daarbinnen bijv.). Zodoende kan ieder project op zijn eigen manier zijn assmblies zo inrichten dat er uiteindelijk de assembly mee gemaakt kan worden, alleen is er geen overall structuur voor elke assembly bedacht; de vraag is ook of je elk .csproj in dezelfde keurslijf kunt gieten.

Je kunt niet meerdere vs.net projects in 1 assembly stoppen. Je kunt alleen op de command line naar meerdere modules compileren en die in 1 assembly stoppen maar dat wil je echt niet, trust me.

Ik krijg verder de indruk dat er een groot project moet worden opgezet maar dat niemand ook maar een flauw idee heeft hoe dat zou moeten. Dit resulteert veelal in veel vergader waar geen reet besloten wordt.

Je kunt met een message broker onafhankelijk met verschillende assemlies communiceren door te serialiseren, echter dat heeft weer licentietechnische gevolgen, het mag natuurlijk niet veel kosten, dus dat is waarschijnlijk geen optie, maar ik noemde zodat er misschien wat ervaringen geplaatst zouden worden...;)

Ik weet niet wat je wilt vertellen maar wat je hier letterlijk zegt is onzin. Assemblies communiceren niet stand-alone en als je remoting bedoelt heb je geen licensie perikelen.

Oh en niet teveel kosten? Je zit met 80 man aan een project te werken. Dat gaat tonnen kosten. Oh en huur een ervaren projectleider in die er niet voor terugdeinst developers uit het project te gooien wanneer ze guidelines niet in acht nemen, want anders zit je over een jaar nog ong. in dezelfde situatie.

[ Voor 28% gewijzigd door EfBe op 12-01-2005 09:44 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

woensdag 12 januari 2005 10:02

-= Tja =-

EfBe schreef op woensdag 12 januari 2005 @ 09:37:
En dat doe je VER NADAT je de functionaliteit hebt ontworpen. Of ga je alles agile/XP achtig benaderen?

De Agile stroming staat niet voor 'geen design'. Het staat voor 'geen onnodig design'. En verder wordt niet alles tot in de kleinste details uitgewerkt. Dit maakt dat je veel flexibeler bent (er is tenslotte minder werk om weg te gooien). En dit heeft als gevolg dat je eenvoudig wijzigingen kunt aanbrengen omdat de klant andere requirements aanvoert of omdat je het probleem beter leert begrijpen. Verder geloof ik dat de kracht van de Agile stroming voornamelijk ligt in de wat kleinere projecten...

[ Voor 3% gewijzigd door Alarmnummer op 12-01-2005 09:44 ]

Acties:

woensdag 12 januari 2005 10:22

Alarmnummer schreef op woensdag 12 januari 2005 @ 09:44:
De Agile stroming staat niet voor 'geen design'. Het staat voor 'geen onnodig design'. En verder wordt niet alles tot in de kleinste details uitgewerkt. Dit maakt dat je veel flexibeler bent (er is tenslotte minder werk om weg te gooien). En dit heeft als gevolg dat je eenvoudig wijzigingen kunt aanbrengen omdat de klant andere requirements aanvoert of omdat je het probleem beter leert begrijpen.

Weet ik, maar het nadeel ervan is dat je geen functioneel ontwerp meer maakt dat de complete applicatie beschrijft en die top down uitwerkt tot je technisch ontwerp. Dit houdt dus in in grote projecten dat je bij grenzen van subprojects je erg moet oppassen wat je doet en het ene team niet zomaar wat kan besluiten.

Daarom geloof ik ook niet in agile development. Vroeger heette dat ad-hoc prutsen, tegenwoordig heeft het een naam... Tuurlijk zitten er goede dingen in, zoals je zelf ook aangeeft: je moet niet teveel doorontwerpen vooraf, echter mijn indruk is dat de agile movement zelf die grens waar je moet stoppen met ontwerpen van details wel erg snel legt en dus eigenlijk een functioneel ontwerp afkeurt. Daarmee maak je je project onbeheerbaar, want over 2 jaar, waar kan ik de link terugvinden tussen class ABC en de functionele beschrijving van de functionaliteit die het realiseert?

Verder geloof ik dat de kracht van de Agile stroming voornamelijk ligt in de wat kleinere projecten...

Behalve meneer Fowler zijn veel mensen daar idd gelukkig van doordrongen

Ontopic

Je kunt "afgebakende functionaliteit" of subsystemen (what's in the name) classificeren:

1) utilities: oftewel libraries die geen verwantschap hebben met andere libraries en op zichzelf staan, zoals wiskundige routines, etc.etc.
2) mini subsystemen: deze assemblies bieden functionaliteit die door verschillende projecten hergebruikt worden én waar een user interface aan vast zit en waar een geringe mate van onderlinge assembly afhankelijkheid in zit (deze subsystemen hebben voornamelijk referenties naar de 1e categorie assemblies)
3) specifieke subsystemen: deze assemblies hebben gerichte/specifieke functionaliteit die niet herbruikbaar is door andere projecten, maar deze categorie maakt wel weer gebruik van categorie 1) en 2) assemblies.

Ik weet niet uit welk leerboek je dit haalt maar dit gaat niet werken. Het klinkt allemaal veel te algemeen, je kunt het niet toepassen op jouw specifieke situatie. Immers, wat houdt 2) in? User controls met hun eigen BL en DAL?

Waarom schuift men 20 jaar oude technologie van Yourdon cs. (ja heb je hem weer) aan de kant? Begin bij de functionaliteit: WAT moet je maken, en WAAROM, dan ga je daarin strepen wat WERKELIJK nodig is (i.e.: je 1e rauwe functioneel ontwerp, gebaseerd op research zoals interviews, levert veelal een superset van functionaliteit waaruit je de subset van functionaliteit distilleert die je gaat implementeren). Dan ga je daar een technisch ontwerp van maken, of meerdere technische ontwerpen, al naar gelang je met details wilt werken of niet. Aan de hand van dat technisch ontwerp heb je inzicht (en niet eerder, geloof me) in hoe de innerlijke structuur van je applicatie eruit komt te zien, aangezien je tijdens het opstellen van je technisch ontwerp ontwerpkeuzes maakt.

[ Voor 37% gewijzigd door EfBe op 12-01-2005 10:20 ]

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties:

woensdag 12 januari 2005 14:40

-= Tja =-

EfBe schreef op woensdag 12 januari 2005 @ 10:02:
[...]
Weet ik, maar het nadeel ervan is dat je geen functioneel ontwerp meer maakt dat de complete applicatie beschrijft

Bij de Agile stroming maak je zeker wel een functioneel ontwerp. Alleen het technisch ontwerp hou je vrij licht.. Maar je zorgt er wel voor dat het gene dat je ontwerp erg goed in elkaar zit.

Daarom geloof ik ook niet in agile development. Vroeger heette dat ad-hoc prutsen, tegenwoordig heeft het een naam...

Dat ben ik niet met je eens. Als de Agile stroming wel ergens goed in is, is het neerzetten van een goed en krachtig ontwerp. Ze stellen alleen veel details uit tot een later tijdstip. Maar het wil absoluut niet zeggen dat ze dus er maar op losprutsen....

Daarmee maak je je project onbeheerbaar, want over 2 jaar, waar kan ik de link terugvinden tussen class ABC en de functionele beschrijving van de functionaliteit die het realiseert?

Agile stroming staat ook niet voor... fuck de documentatie..

Behalve meneer Fowler zijn veel mensen daar idd gelukkig van doordrongen

Mwuah... als ik eerlijk ben.. Fowler en cornuiten staan in het lijstje met 'erg veel verstand van zaken.. en verdomd veel verstand van architectuur' toch wel boven aan mijn lijstje. Ik ben het niet met je eens dat het een paar losgeslagen knoeiers en prutsers zijn die erop los aan het knoeien zijn. En verder moet je niet vergeten dat Fowler een erg goed auteur is, maar dat achter hem een enorm lading dude`s staan die wat minder bedreven zijn in het schrijven.. maar meer in het ontwerpen.

[edit]
En niet alle projecten zijn mega projecten. Gemiddeld zitten wij hier met 2 a 3 man op 1 project, en de standaard projecten zijn qua complexiteit redelijk te overzien.

[ Voor 11% gewijzigd door Alarmnummer op 12-01-2005 10:35 ]

Acties:

woensdag 12 januari 2005 15:36

Alarmnummer schreef op woensdag 12 januari 2005 @ 10:22:
Bij de Agile stroming maak je zeker wel een functioneel ontwerp. Alleen het technisch ontwerp hou je vrij licht.. Maar je zorgt er wel voor dat het gene dat je ontwerp erg goed in elkaar zit.

Lijkt me toch wat in tegenspraak met XP, een van de hoekstenen van agile development.

Dat ben ik niet met je eens. Als de Agile stroming wel ergens goed in is, is het neerzetten van een goed en krachtig ontwerp. Ze stellen alleen veel details uit tot een later tijdstip. Maar het wil absoluut niet zeggen dat ze dus er maar op losprutsen....

Het is maar hoe je het bekijkt natuurlijk

In een klein team kun je details uitstellen tot later, in een groot team echt niet, en je kunt ZEKER NIET het nadenken over eventuele gevolgen van gekozen grote lijnen uitstellen tot later (waar je dus in detail moet duiken, hoe je het ook wendt of keert).

Ik ben zelf een one-man-army dus ik ga niet voormezelf ieder detail uitpriegelen in een worddoc, maar ik kan me voorstellen dat in een 80-man groot team zoals hier je dat echt niet moet doen want dan krijg je de grootst mogelijke problemen. Bij microsoft zie je dat goed hoe ze het organiseren: een mega project zoals windows xp wordt superhierarchies opgebouwd in allerlei kleinere onderdeeltjes totdat je bv uitkomt bij een knop op de taskbar waar 1 PM en 2 developers aan werken en die zijn de 'eigenaar' van die feature, die weer onderdeel uitmaakt van een grotere feature die weer eigendom is van een ander groepje etc. Dan ga je niet details uitsmeren tot 'later' want je krijgt dan de grootst mogelijke ellende: de een denkt dat hij het zo moet oplossen en een ander teampje doet het compleet andersom met als gevolg dat het niet efficient samenwerkt.

Agile stroming staat ook niet voor... fuck de documentatie..

Dan moet je me toch eens uitleggen waar XP dan zn documentatie schrijven tasks definieert.

Mwuah... als ik eerlijk ben.. Fowler en cornuiten staan in het lijstje met 'erg veel verstand van zaken.. en verdomd veel verstand van architectuur' toch wel boven aan mijn lijstje. Ik ben het niet met je eens dat het een paar losgeslagen knoeiers en prutsers zijn die erop los aan het knoeien zijn. En verder moet je niet vergeten dat Fowler een erg goed auteur is, maar dat achter hem een enorm lading dude`s staan die wat minder bedreven zijn in het schrijven.. maar meer in het ontwerpen.

Het is jammer dat ik niet naar Lillehammer gegaan ben vorige week anders had ik het hem zelf kunnen vragen, maar mijn indruk is iig dat het mooi staat op papier maar het teveel 'ad-hoc' is, immers XP vereist dat je niet veel tijd kwijtraakt aan geneuzel vooraf, want men gaat ervan uit dat veel geneuzel vooraf veelal te maken heeft met 'het zou kunnen dat wellicht in de toekomst' terwijl dat helemaal niet zo hoeft te zijn. Op zich nobel streven, maar het resulteert wel in een focus op 'wat nu werkt is belangrijk', iets wat grote kans loopt op de beroemde muur waar het met volle vaart tegenaan crasht vanwege een onvoorziene omstandigheid wanneer het grote geheel bijelkaar komt.

En niet alle projecten zijn mega projecten. Gemiddeld zitten wij hier met 2 a 3 man op 1 project, en de standaard projecten zijn qua complexiteit redelijk te overzien.

tuurlijk, dat spreekt voor zich, echter diezelfde factoren zijn niet echt meer van toepassing bij het project waar TS over praat. Als ik kijk hoe sommige klanten van ons hun projects organiseren (projecten met databases van 1000 tables of meer), waarbij 20-30 man alleen aan de gui werken en absoluut niets mogen behalve gui code schrijven dan snap je ong. dat in dat soort projects niets aan het toeval over kan worden gelaten anders loopt het in het honderd, immers alleen wanneer je dingen regelt heb je een redelijke kans dat het ook gebeurt, wanneer je hoopt op de inzicht van de developer heb je die kans ook maar het risico dat de developer het verkeerd ziet is stukken groter en in grote projecten onacceptabel groot, want het gaat niet om een paar pakken koffie in veel gevallen.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Acties: