[.NET/C#] Architectuur beslissing n-tier

Pagina: 1
Acties:

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Momenteel wordt middels COM/COM+ (MTS,MSMQ) en VB 6 de applicatie vorm gegeven. Nu kun je middels die package wizzard snel en handig die installtie voor componenten maken en bij de installatie simpel aangeven waar welke COM draait (fysiek dan).

Wat is nu precies de .NET tegenhanger van die concept?

System.Runtime.Remoting / Webservices en ik heb iets gelezen van een wsdl.ex tool om een proxy te creeren. Nu is mijn vraag of iemand hier al naar gegeken heeft...praktisch toegepast. De zaak wordt gedistribueerd in een Windows netwerkje dus de VB 6 way voldeed prima wat installatie betreft (gewoon even aangeven waar de COM's draaien en klaar). Ikke hebbe een:

SQL Server
--
DataAccess
--
BusinessRules
BusinessFacade
--
Client / Webservices
--
WebClients

waarvan ik 3 fysieke opdelingen wil maken... DataAcces/Business/Client

Hoe/middels welke technieken doen jullie dat of juist niet...?

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
schopje

Verwijderd

Om geen lang verhaal te hoeven tikken: zorg ervoor dat je de tiers zo opdeelt dat het black boxes vormen voor de tier-consuming layers. Klinkt wellicht wat algemeen, maar iets anders is er IMHO niet. MS levert bij VS.net enterprise /architect een aantal framework projects mee, waar soms 5 soms 7 tiers inzitten. Ik vind dat wat overbodig, temeer omdat ze bv 2 tiers gebruiken voor de client: de client facade en de client layer zelf. Ik denk dat dan die facade layer gewoon bij je bl layer in kan.

Ik denk dan ook dat je bv je middle-tier niet als 1 tier moet zien maar als een verzameling services, dus soms een webservice, soms een BL layer met classes.

HTH

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Ik ben al ff bezig met die Fitch & Mathers case te bestuderen, maar das geen simpel karwei om het zo maar eens te stellen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
        /// <summary>
        /// Method used to determine the location of the components. First we
        /// assume that everything is running locally. Then we try to read the
        /// remotingclient.cfg file to see if either the GAM or the BLL are being
        /// remoted. If we find either of these entries, we use that machine 
        /// name.
        /// </summary>

        private static void LocateComponents()
        {
            string computerName = Environment.GetEnvironmentVariable( "COMPUTERNAME" );         
            Regex urlRE    = new Regex(@"^(\w+)://([\w\-\.\d]+)(.*)$");         
            Regex typeRE   = new Regex(@"^([^,]+),([^,]+)$");           
            
            string path = Path.Combine(applicationPath,"remotingclient.cfg");
            if(File.Exists(path))
            {
                path = Regex.Replace(path,@"\\",@"\\");
                ManagementPath.DefaultPath = new ManagementPath("root\\NetFrameworkv1");
                string query = string.Format("select * from client_wellknown where Selector=\"file://{0}\"", path);
                                                            
                ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);
                ManagementObjectCollection wkos = searcher.Get();               
                foreach(ManagementObject mo in wkos)
                {                               
                    string url     = (string)mo.Properties["url"].Value;            
                    string typeAsm = (string)mo.Properties["type"].Value;                                       
                    string machine = urlRE.Split(url)[2].Trim();                
                    string type    = typeRE.Split(typeAsm)[1].Trim();               
                    
                    if(type=="FMStocks7.GAM.GAMClass")
                    {
                        computerName = machine;                     
                        break;
                    }
                    if(type=="FMStocks7.BLL.Version")
                    {
                        computerName = machine;
                        isBLLRemoted = true;                        
                        break;
                    }
                        
                }
            }
                    
            if ( gamMachineName == null )
                gamMachineName = computerName.ToUpper();            
        }

Die gekken gaan zelfs handmatig coden wat waar welke componenten aanroepen etc etc. Weet jij "Otis" of wellicht iemand anders niet een fatsoenlijk kleine, strakke voorbeeld applicatie waarin het functioneel mogelijk is om de applicatie logica te splitsen over 3-tieren (Business, DataAccess, Presentation) en wel gedistribueerd... eventueel load ballanced. Ben namelijk al zeker 2 dagen aan eht zoeken en code fragmenten bestuderen...en nog geen stap verder.

Verwijderd

Hangt dat niet van je specifieke geval af? Voorbeeld: mn bugtracker systeem in aanbouw heb ik zo verdeeld:

webclient + dotnet client
-------------------------
webservice
----------
business logic
----------
data-access


De reden hiervoor is dat ik de webservice als standalone wil aanbieden. Wil je dit niet, dan gaat die laag er tussenuit want waarom zou je het dan zo doen?

Ik denk dat je moet definieren welke functionaliteit je hebt en op welke manier je die functionaliteit kunt implementeren. Maak bv 2 of 3 case studies daarvan: schrijf per methode op welke voor en nadelen er aan kleven. Kies daarna de methode die voor jouw situatie het beste is. Er is geen eenduidige methode met een rijtje stappen hoe iets af te beelden op 3 tiers. Tiers zijn ook maar abstracte boxes om scheiding tussen functionaliteit aan te geven zodat je langs die scheidslijnen kunt scalen + hergebruiken. Maw: het moet een middel zijn, geen doel op zich. Pin je dus niet vast op '3 tiers', als 4 of 5 tiers voordeliger is.

Wat voordeliger is weet je pas na onderzoek, dus wat moet er worden gebouwd, hoe kan dat, wat zijn de voor en nadelen van de oplossingen die verzonnen kunnen worden. Saai wellicht, maar dat hoort erbij, een Technisch Ontwerp is niet voor niets noodzakelijk voor een applicatie.

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Ja ik heb al een redelijk beeld hoe de tiers in te vullen, maar het probleem is dat ik 1..2..3 niet weet hoe dit in .NET in te passen. Op de een of andere manier absorbeer ik die distributed documentatie niet.

Concrete vraag, hoe implementeer jij "distributed" dus met andere woorden hoe laat jij je progje weten op welke server welk component draait en eventueel ook nog eens load ballenced implementeerd.

Het n-tier model is vrij duidelijk en die assemblies compileren is ook het probleem niet, maar dat laatste kleine stapje nog...

Nog even wat toelichten:

Ik heb de DataAccessLogic in 1 assemblie zitten met daarin de klasse gegenereert met jouw tool en een SQLQuery interface om losse queries uit toe voeren indien deze niet stored zijn

een wrapper om de DataAccessLogic heen oftewel de DataAccessWrapper welke als serviced component door het leven gaat

BusinessLogic als 1 assemblie

Alle losse componenten hebben een stukje BusinessFacade allemaal losse assemblies dus

en de views, welke gewone executables zijn en de Businessrules en Facade linken

Dan nog een Common voor configuratie, Bugtracking en profiling

Verwijderd

Op woensdag 01 mei 2002 14:47 schreef paulgielens het volgende:
Ja ik heb al een redelijk beeld hoe de tiers in te vullen, maar het probleem is dat ik 1..2..3 niet weet hoe dit in .NET in te passen. Op de een of andere manier absorbeer ik die distributed documentatie niet.
Concrete vraag, hoe implementeer jij "distributed" dus met andere woorden hoe laat jij je progje weten op welke server welk component draait en eventueel ook nog eens load ballenced implementeerd.
Dat doe ik niet. Ik werk met black boxes, indien het distributed is. Ik ga dus niet componenten lukraak op servers plaatsen, maar kijk daar tegenaan als service. Zo bouw ik waar nodig logica in SQLServer, zodat je daar scaling kunt aanbrengen plus je praat tegen 1 service, niet tegen een serie aan verspreide blokken. Idem met de lagen daarboven. Met .NET is het erg versimpeld: je kunt nu webservices aanmaken voor distributed tiers, dus een logische API voor een blok functionaliteit die je gebruikt in je applicatie. Daar deel ik mn applicaties in op, indien nodig.

Maar dit kan per applicatie verschillen: per applicatie is de zwaarte per tier anders, en is om goede scaling te krijgen, een andere plaatsing van de functionaliteit nodig. Nu moet je niet 10 webservices op elkaar stapelen, maar je moet ze naast elkaar plaatsen. Dan krijg je scaling en dat is wat je wilt. Teken het maar eens uit, dwz de functionaliteit, en kijk maar eens waar je die kunt opdelen in onafhankelijke zaken.

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Ja ik vat hem... ik praat dus echt over load ballancing/distributed om dus runtime componenten te gaan vervangen. Tis voor een proces informatiesysteem waarbij de productie dus niet plat mag komen te liggen indien componenten vervangen of toegevoegd worden. Komt nog eens bij dat we een dergelijke feature ook graag voor de huidige performance problemen willen toepassen. Probleem is dat ik niet 1 fatsoenlijk voorbeeld van een dergelijk systeem kan vinden.

Ik weet dat in Java load ballancing middels CORBA aardig lekker werkt, maar wat de tegenhanger is in .NET... no idea.

Graag zou ik dus wat ervaringen horen van andere .NET gebruikers, maar tis zomaar akelig stil hier in dit topic.

Verwijderd

Het vervangen van runtime componenten is in .NET geen probleem (was het altijd wel met MTS/COM+ aaaaarg): assembly copieren, klaar.

Load balancing is imho niet iets wat in 'corba' ingebakken zit, je zult altijd een load balancer moeten gebruiken, bv een hardwarematige die connections scheduled over meerdere machines. Je zou dus bv meerdere machines met dezelfde webservice kunnen installeren en daarvoor een load balancer plaatsen. Dit gaat imho goed omdat het gebruik van webservices stateless is: heen: call, terug: result, einde.

'load balancing' is wel een buzzword, vergis je er niet in. Veelal is het goed verdelen van de functionaliteit over bv de middle-tier doos en de sqlserver doos al voldoende voor een meer dan toereikende performance.

Als je je tier grenzen goed definieert (dwz op de juiste plaats) dan moet het mogelijk zijn de tiers redundant op te nemen in je traject van client -> database / state collector -> client. Waar je dan load balancers plaatst om de druk te verdelen is niet zo'n punt, maar wel voor de redundant opgenomen tiers.

Feit blijft dat alles zo stateless mogelijk moet worden uitgevoerd, zodat het opnemen van meer redundancy, geregeld via hardwareloadbalancers, geen problemen oplevert. Maar dit is logisch.

Is de load balancing voor pure redundancy in het traject in het geval van falen of om inmense pieken op te vangen?

  • OMX2000
  • Registratie: Januari 2001
  • Laatst online: 07:45

OMX2000

By any means necessary...

Dè developers podcast in je moerstaal : CodeKlets Podcast


  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
het is voor een process informatiesysteem...stel je voor de complete aansturing van Heineken. Zowel op laag nivo middels IO en profi bussen. En natuurlijk een FrameWork, bij ons in Java geschreven. Daarop draait een top-level systeem voor systeem operators VB 6/MSMQ/MTS/SQL Server 7 verdeel over enkele view stations, servers, workstations. Momenteel is het 1 grote componenten soep (door de bomen het bos niet meer zien). Ik ben naar .NET / C# /VB.NET aan het kijken of alles in Data->DataAcceslogic->BusinessLogic->BusinessFacade->Presentation => Common te gieten is zodat er dus t/m de BusinessAccess 3 assemblies zijn. Nu zijn dat er voor deze lagen al zo'n kleine 20+, allemaal losse troep en redunante code.

Load ballenced is dus voornamelijk voor de service aan componenten, niet direct voor performance zaken. Het systeem moet wel gedistribueerd zijn aangezien alles over meerdere servers verdeeld wordt. Als ik dan naar die .NET voorbeelden zit te kijken is dat distribueren dus helemaal niet eenvoudig allemaal erg vaag. Hoe laat je de ene assemblie weten waar de andere draait bv? Hoe verander je dat runtime...is dat wel mogelijk etc etc. Alle voorbeelden van MS zijn webenabled applicaties, waar ik dus niets aan heb. Die FMStocks is weer vet ingewikkeld, kan me haast niet voorstellen dat gedistribueerd ineens zo moeilijk is aangezien VB6 gewoon code is/referentie leggen en een package maken. Bij de installatie van de package kun je netjes alle systemen intikken waar het betreffende component wat gerefereerd is draait (gewoon in windows netwerk)

maargoed ik zal eens even de zaken doornemen bedankt heren

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Op woensdag 01 mei 2002 20:01 schreef OMX2000 het volgende:
Dit artikel legt veel uit: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/entserv.asp
danku

  • OMX2000
  • Registratie: Januari 2001
  • Laatst online: 07:45

OMX2000

By any means necessary...

oh ja vooral het gedeelte onder Remote Components is voor jou van toepassing...

Dè developers podcast in je moerstaal : CodeKlets Podcast


  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
btw Otis: Een assemblie vervangen terwijl deze in gebruik is, is dus niet mogelijk. OS zal dat waarschijnlijk niet toelaten wat het vervangen van componenten zoals jij dus spiegelt niet mogelijk maakt. Of mis ik iets?

Verwijderd

Op donderdag 02 mei 2002 08:18 schreef paulgielens het volgende:
btw Otis: Een assemblie vervangen terwijl deze in gebruik is, is dus niet mogelijk. OS zal dat waarschijnlijk niet toelaten wat het vervangen van componenten zoals jij dus spiegelt niet mogelijk maakt. Of mis ik iets?
Volgens mij gaat dat goed, dat is nl. het voordeel van assemblies tov COM dll's. Je kunt dus assemblies die gebruikt worden in bv webapplicaties gewoon vervangen door de nieuwe dll er overheen te kopieren. De runtime zal zien dat de assembly is gewijzigd en zal de nieuwe inladen.

VS.NET locked sommige assemblies, ivm de editor. Er zit geen filelocking meer op assemblies. In het artikel wat hierboven is gelinkt (erg slecht artikel overigens, veel detailinformatie en warrrige uitleg) gaat men ook in op 'xcopy' deployment van serviced components.

  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
Dan heb ik te vroeg geroepen, jah ik ik heb al meerdere malen gemerkt dat assemblies gelocked worden in VS.NET.

Ik heb trouwens wat materiaal gelezen, maar kan nergens duidelijk vinden hoe je nou zo'n installtie knutseld. Stel ik heb een COM server en een COM client waarvan de server remote draait, binnen een windows netwerk wel te verstaan. In vb6 kon je dan een package maken en bij de installtie van de client aangeven op welke machine de betreffende referentie server draait zodat het proxy object de weg weet naar zijn "stub-> server component". Hoe realiseer je zoiets in .NET? Door zo'n msi installer te maken, maar hoe exact want ik kan dat in de deployment documentatie nergens vinden.

Verwijderd

Op donderdag 02 mei 2002 10:20 schreef paulgielens het volgende:
Ik heb trouwens wat materiaal gelezen, maar kan nergens duidelijk vinden hoe je nou zo'n installtie knutseld. Stel ik heb een COM server en een COM client waarvan de server remote draait, binnen een windows netwerk wel te verstaan. In vb6 kon je dan een package maken en bij de installtie van de client aangeven op welke machine de betreffende referentie server draait zodat het proxy object de weg weet naar zijn "stub-> server component". Hoe realiseer je zoiets in .NET? Door zo'n msi installer te maken, maar hoe exact want ik kan dat in de deployment documentatie nergens vinden.
Vziw moet dan op de client PC een stub dll worden geinstalleerd die de calls doorsjoelt naar de machine waar de COM server op draait. De COM client DLL denkt dat de COM server lokaal draait. Die stub dll wordt gegenereerd door COM+ services wanneer je een package export in de COM+ snap-in :) Die maakt keurig een COM+ stub installer aan.
(zorg dat je package een 'server' package is, geen library package)

- RMB op package naam
- kies 'export'
- klik next en dan naam intikken en onderste optie kiezen (application proxy)
- klik next en finish

je dll installer is klaar. Runnen op client bak en voila.

Omdat vziw die serviced components ook in een COM+ package (application) moeten worden geregistreerd zal dit goed gaan.

  • OMX2000
  • Registratie: Januari 2001
  • Laatst online: 07:45

OMX2000

By any means necessary...

nog een leuk artikel :http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet04232002.asp

Dè developers podcast in je moerstaal : CodeKlets Podcast


  • Scare360
  • Registratie: Juli 2001
  • Laatst online: 07:57
danku, want het ging nog steeds niet perfect...

  • whoami
  • Registratie: December 2000
  • Laatst online: 09:11
Nog een artikel waar je misschien wel mee verder kunt:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetarch001.asp?frame=true

('k heb het zelf nog niet doorspit).

https://fgheysels.github.io/

Pagina: 1