ASP.net intranet i moduler

Det er der rigtig mange muligheder for - og der er en hel del forskellige måder at lave det på :o)
Jeg vil gerne deltage her, men jeg skal lige have fri først ;o)
Mvh

Evt. links til sider og titler på interessante bøger er selvfølgelig også i interesse :)

Findes der en måde, hvorved man kan inherit funktioner m.m. fra en anden webapplikation?

[bare lidt kommentarer om løst og fast]

ASP.NET er fuldt objekt orienteret og understøtter arv. Du kan sagtens lade
dine sider arve fra en code behind klasse og alle code behind klasserne kan
arve fra en fælles base class.

Men det tror jeg ikke giver noget. Code behind indeholder logikken og logikken
er forskellig mellem siderne.

Det du skal er:

1)  have en måde at administere/konfigurere modulerne

2)  sikre en ens look and feel

re #2)

* det hjælper at det hele er lavet i ASP.NET

* I kan lave nogle CSS og mandate at alle developere bruger dem

* I kan lave en guide der fortæller hvordan det skal gøres

* I kan lave et pænt stort library med delt funktionalitet og dokumentere det

* måske kan I kigge på ASP.NET User Controls

re #1)

Dette er faktisk ikke så ASP.NET specifikt. Det kendes i alle server side web
sprog.

I skal:

A)  have lavet en model for hvordan det skal gøres og dokumenteret den så
    dem der laver moduler ved hvordan de skal gøre

B)  have det implementeret teknisk i hoved applikationen

re #B)

De to mest gængse løsninger er:

* den simple/primitive/nemme løsning en konfigurations fil

* den avancerede/sofistikerede/dyre løsning med data i databasen og
  et administratiosn modul (som kommer med hoved applikationen)

Jeg er lidt bange for at folk idag har forventninger om det sidste.

Nu ved jeg så ikke præcist hvad det er din hovedkerne skal kunne, men du kan godt lave en nogle librarys med hhv. en vifte af kontrollerne der kan bruges til at opbygge nye sider med, og nogle baseforms med nogle specifikke formål.

du kan så distribuere disse klodser som en installerbar pakke, som man i et lokalt projekt (et eller andet sted i virksomheden) kan oprette referencer til. Det vil så give den enkelte udviklingsgruppe et godt udgangspunkt for at oprette nye sider / tilføje funktionalitet.

kernekontrollerne (eller hvad vi nu skal kalde dem) kan så bygges så de kan nedarves til specialiserede kontroller i det enelte projekt.

Hvis du benytter brugerkontroller skal du være opmærksom på, at der er nogle problemer med at dele dem på tværs af applikationer.

Men.... kan du ikke komme med nogle bud på noget konkret funktionalitet der kunne være behov for. Det er næsten lidt for abstrakt det du har skrevet til at jeg kan give dig et reelt eksempel, men kom endelig med noget - så skal jeg se om jeg kan strikke noget illustrativt sammen du kan kigge på.

Har du for øvrigt kigget på en Microsoft Sharepoint Portal ?

Mvh

Her er lidt af det jeg havde tænkt mig:

En løsning, hvor man har en kerne, som udbyder funktioner og procedurer til de forskellige moduler, herunder kommunikation med det underliggende system, så modulerne kun skal lave en forspørgsel til kernen, f.eks. Kerne->GetSystemHeartBeat(sysID) - således at modulerne via Kerne kan fange de public procedurer og funktioner...

Sådan som jeg gerne ville have det, var at hvis man f.eks. havde en struktur i kernen: /Intranet/Moduler/* hvor alle modulerne lå som selvstændige løsninger, f.eks. /Intranet/Moduler/SysWatch - hvor SysWatch var en selvstændig projekt, med egen DLL, m.m., men samtidig kunne bruge funktioner der blev udbudt public i kernen, som beskrevet ovenfor...

Alle moduler havde så en config.xml som beskrev hvad der skulle gøre i kernen, f.eks. hvilke menu-punkter der skal add'es i menuen (kernen), internt projektID, nøgler m.m.

Mht. administrations-modul, skal der selvfølgelig være et modul i kernen hvor det er muligt at add'e og fjerne moduler - dette vil jeg helst gerne holde i XML-filer. Yderligere havde jeg regnet med at integrere noget versions-styring, så det er muligt at opdatere enkelte moduler, f.eks. ved at uploade en Zip-fil med modulet i, som automatisk ligger sig ind over det gamle modul... Men det er jo fremtid...

Det er hvad jeg lige har gjort mig af tanker lige nu...

Grundig og løbende dokumentation af public funktioner til kernen vil selvfølgelig blive publiceret til involverede udviklere...

Med et administrations modul ville jeg vælge database fremfor XML for config.

Det andet kan give nogle sjove fler bruger problem stillinger.

Det er egentlig for at gøre selve systemet fri for brug af database, så de systemer det køre på kan bruge database-serverne fuldt ud til informationerne på intranettet - men det er jo en mindre detalje...

XML-filerne var kun tiltænkt konfiguration af systemet, som f.eks. versions-styring m.m.

Virkelig ingen der kan hjælpe med nogle referencer til steder med problemstilling, løsninger, artikler, bøger m.m.?

Jeg har lavet temmelig meget af den slags, og der er virkelig mange måder at gøre det på - det er nok derfor det er lidt svært lige at lægge lidt info ud omkring det.

Mange af de ting du beskriver - er sådan set en ganske normal måde at opbygge en solution på, hvor du har en række projekter med referencer imellem.

hvis du er interesseret i, at kunne skifte et modul ud med et nyere, vil det være hensigtsmæssigt at definere nogle interfaces.
en assembly der indeholder en klasse, der implementerer et givent interface vil så kunne indgå... uanset hvad assemblien så ellers kan bruges til.
du kan lige få lidt kode til det sidste om lidt... det ligger i et endet spm her på eksperten.

Nedenstående er fra http://www.eksperten.dk/spm/528807

// et interface
public interface ISomething
{
    string GiveMeSomething();
}

interfacet er så implementeret på en klasse i en given assembly, og du "peger så på den i en konfigurationsfil" :

<add key="AssemblyName"    value="SomeAssembly" />
<add key="Namespace" value="Some.Namespace" />
<add key="Class" value="SomeClass" />

// du kunne så have noget i stil med nedenstående i en factory-klasse :
// Config er så bare der hvor du suger din konfiguration
public static ISomething CreateSomething()
{
    return (ISomething)CreateObject(Config.Namespace, Config.AssemblyName, Config.Class);
}

// der bruger denne her :
public static object CreateObject(string nameSpace, string assemblyPath, string className)
{
    return Assembly.Load(assemblyPath).CreateInstance(nameSpace + "." + className);
}


Et eller andet sted hvor du har lyst til at bruge den :

ISomething something = Factory.CreateSomething();
string text = something.GiveMeSomething();

Det er en måde hvorpå du kan sikre dig at en mulighed for at opbygge dit samlede system af blokke med kendte formål... måden hvorpå blokken opfylder formålet er så frit til at implementere på den måde der passer i en given situation.

Jeg prøver at sætte mig ind i det, men en hurtig solution, med to projekter der nedarver funktioner og klasser, ville være suprime - er det havd ovenstående kodesnip demonstrere?

Det jeg ønsker er jo, at jeg fra WebApp2 kan accesse funktioner i WebApp1 - altså på tværs af to WebApps

hvis jeg skulle sende dig en solution skulle der sendes filer... jeg kan ikke bare skrive det her.

har du ikke prøvet at lave en reference fra et projekt til et andet i f.eks. visual studio ?

jeg er blevet temmelig forvirret over det sidste du skrev... hvis du vil kalde noget fra et web til et andet er det én ting. hvis du i forbindelse med produktion af assemblies vil kunne subclasse diverse "kerne-klasse" er det noget helt andet.
hvis du ønsker at have metoder tilgændeligt på intranettet som returnerer forskellige ting og sager er det en helt tredie ting (web-services er så nok mere relevant f.eks.)

Jeg formulerer mig måske ikke klart nok... Det eneste jeg ønsker, pt., er som optegnet i http://benne.dk/plan.jpg - altså en webapplikation, der kan benytte funktioner i en anden :)

Problemet er lidt at dit spørgsmål i sin brede fortolkning er at du vil se
en ASP.NET portal løsning i hundredetusind/millioner kroners klassen og
i en smal fortolkning er elementær ASP.NET som kan tages ud af enhver lærebog.

Dit sidste billede vil i smal fortolkning løses ved:

1)  lave en klasse IntranetKerne
2)  med 4 static metoder
3)  compile den til DLL
4)  gør DLL tilgængelig for all moduler

Jeg helt enig med arne i hans beskrivelse af hvorfor det er lidt svært at komme med gode bud :o)

Jeg ville bare lave en lille webservice til det....

Umiddelbart synes jeg ikke at web service lyder relevant.

web service - loosely coupled technological heterogenous

ikke web service - tigtly coupled technological homogeneous

helt enig - men jeg synes der er lidt divergens imellem det der skrives her, og det der vises på billedet.
herinde står der f.eks. kommunikation på tværs af webs, og men på billedet ligger det hele under samme web.

hvis behovet er, at der kontinuerligt skal kunne produceres nye sider på samme skabelon (synes jeg også der har været lagt op til her) - har du selv givet en opskrift højere oppe, og hvor din klasse med de 4 statics i meget vel kunne indgå.
jeg synes bare at punkt 4 ofte giver lidt problemer - og hvis behovet reelt ikke er til det.

jeg er bare i tvivl om hvad der skal opnås - og webservicen var ment som en simplificering, såfremt behovet bare var som skrevet i http://www.eksperten.dk/spm/530028#rid4860615 (og tænkt som et uvist antal webapplikationer der skulle bruge samme services).

heidi... kan du ikke fortælle lidt mere om hvad Get/SetSysA, og Get/SetSysB går ud på ? jeg synes jeg har svært ved at trække http://www.eksperten.dk/spm/530028#rid4857585 ud af billedet.

Med venlig hilsen

heidi>

Tid at få afsluttet spørgsmålet ?

Og et svar fra mig såfremt nogle af mine kommentarer har været nyttige.

samme her :o)

Heidi ?

??

hvis vi råber i kor kan det være hun vender tilbage ;o)
heidi kan du ikke lukke geschæften her ?
mvh