Toon posts:

[disc]Evolutie van programmeren van business applicaties

Pagina: 1
Acties:

Verwijderd

Topicstarter
De laatste tijd wordt er in de java wereld veel gebruik gemaakt van frameworken per laag in je applicatie. Hibernate voor de persistence laag, struts voor presentatie laag en spring om alles bij elkaar te lijmen.

Hebben jullie ook niet het gevoel dat je voor elke business applicatie zowat hezelfde moet doen: bepalen van het domainmodel, businessrules bepalen van het domainmodel, gui schrijven en de database maken. Meestal komt ook dit weer op hetzelfde werk: domainmodel omzetten naar een database (dit is gewoon regeltjes vormen die je aan iedereen kan aanleren en trouwens rechtstreeks kan afleiden uit het domainmodel).

Voor elk systeem moet er een login voorzien worden, die ook een gui implementatie moet krijgen. Voor elk systeem moet er per domainobject een scherm worden gemaakt waarbij je records toevoegt,verwijderd, opzoekt,..

Waar zit de variatie, de moeilijkheid voor de programmeur? Is het omdat je in de praktijk te maken krijgt met meerdere databases dat je moet koppelen, oude gegevens aan nieuwe, optimalisaties van query's? Waar zit de uitdaging? Dit is misschien ook een antwoord op mijn eigen vraag, Niet iedereen gebruikt access als een oplossing voor zijn bedrijf omdat het simpelweg tekort schiet voor bovengenoemde zaken.

Is er geen manier om bovenstaande te genereren? Database en domainmodel als invoer, n-tier systeem als invoer.

Wat is het nut van het schrijven van een eigen Or/mapper als er Hibernate bestaat, wat is het nut van het schrijven van een eigen MVC voor gui's in java als er JSF en Struts bestaat,

Is er nog toekomst als programmeur van business applicaties als ze in de toekomst misschien kunnen worden gegenereerd?

  • tijn
  • Registratie: Februari 2000
  • Laatst online: 22-03 21:36
Waar zit de uitdaging?
De uitdaging is voor mij om met zo min mogelijk middelen zo veel mogelijk toegevoegde waarde voor eindgebruikers te kunnen leveren. Alle frameworks die mij wat werk uit handen nemen helpen hier stuk voor stuk bij.

Cuyahoga .NET website framework


  • Orphix
  • Registratie: Februari 2000
  • Niet online
Het schrijven van standaard business (web) applicaties is inderdaad heden niet echt meer een uitdaging. Echter het beschrijven van het domein model, het oplossen van problemen waar je klant mee zit. Met creatieve oplossingen komen waar de concurrent niet mee komt. Dat is de uitdaging.

Ik denk dat je uiteindelijk toch altijd de behoefte hebt om net iets verder te gaan, om net voorbij die grens te kijken en op die manier prachtige dingen te bewerkstelligen. Dat dit gepaard gaat met veel gevloek en irritaties omdat de gebruikte frameworks hier niet op gebouwd zijn is logisch, maar je innerlijke intellectuele beloning maakt alles goed ;)

  • whoami
  • Registratie: December 2000
  • Laatst online: 23:34
Iedere enterprise app. is anders, heeft verschillende eisen en functionaliteiten.

Bestaande frameworks nemen heel wat werk uit handen, maar het zal nooit zo zijn dat je een volledige applicatie kunt laten 'genereren'. Het opzetten van een domain-model zal je (zeg nooit nooit) niet kunnen laten genereren, daar is het te complex en te verschillend van geval tot geval voor.

Het is wel zo dat men nu ook bezig is om een soort van 'standaard manier van werken' te bepalen om applicaties te ontwikkelen.
Daar is onlangs ook een boek over verschenen dat ik ooit wel eens zal kopen:
Software factories

https://fgheysels.github.io/


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Ik ben intussen begonnen met 1 (en in de toekomst meer afhankelijk van het soort toepassing) template op te zetten. Waar een kant en klaar project in zit. Alle applicatieserver zaken goed gezet, spring staat klaar, hibernate is geconfigureerd, er is 1 entity, er is 1 service, er is 1 form etc. Er is 1 goed buildscript waar het grootste deel in zit wat je iedere keer nodig bent (unit tests, release/debug wars, etc).

Dus een beetje afhankelijk van het type applicatie, kun je denk ik wel een gedeelte van de saaiheid weg nemen door gewoon even een paar goeie templates op te zetten.

  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Ik heb intussen Middlegen ingezet in de template om aan de hand van metadata uit de db de hibernate config files te genereren en mbv hbm2java alle entiteiten:

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
<target name="generate.dao-from-db"
            description="Generate Hibernate hbm files from db">

        <middlegen  appname="${application-name}"
                    prefsdir="conf"
                    gui="false"
                    databaseurl="jdbc:jtds:sqlserver://192.168.1.160"
                    schema="dbo"
                    catalog="veiling"
                    driver="net.sourceforge.jtds.jdbc.Driver"
                    username="${db.username}"

                    password="${db.password}">

                <hibernate  destination="src/template"
                            package="anchormen.template.entities"
                            javaTypeMapper="middlegen.plugins.hibernate.HibernateJavaTypeMapper"/>

        </middlegen>

        <taskdef    name="hbm2java"
                    classname="net.sf.hibernate.tool.hbm2java.Hbm2JavaTask">

            <classpath>
                <pathelement location="lib-ant/hibernate2.jar"/>
                <pathelement location="lib-ant/hibernate-tools.jar"/>
                <pathelement location="lib-ant/log4j-1.2.8.jar"/>
                <pathelement location="lib-ant/commons-logging-1.0.4.jar"/>
                <pathelement location="lib-ant/commons-lang.jar"/>
                <pathelement location="lib-ant/jdom.jar"/>
            </classpath>
        </taskdef>

        <hbm2java   config="conf/codegen.cfg.xml"
                    output="${src.template}">

            <fileset dir="${src.template}">
                <include name="**/*.hbm.xml"/>
            </fileset>
                        
        </hbm2java>
    </target>


Deze target is trouwens nog niet klaar... zit stuff in dat niet in een template hoort :)

[ Voor 20% gewijzigd door Alarmnummer op 24-12-2004 05:59 ]


  • Eelke Spaak
  • Registratie: Juni 2001
  • Laatst online: 12-05 15:26

Eelke Spaak

- Vlad -

Alarmnummer schreef op vrijdag 24 december 2004 @ 05:59:
Ik heb intussen Middlegen ingezet in de template om aan de hand van metadata uit de db de hibernate config files te genereren en mbv hbm2java alle entiteiten: (...)
offtopic:
Zo doe ik het ook met een project waarmee ik bezig ben. Je moet bij middlegen toch wel alle tabellen nog specificeren (of in ieder geval de many-to-many mappings)? Of zit dat er gewoon niet in omdat het een template is?

TheStreme - Share anything with anyone


  • Alarmnummer
  • Registratie: Juli 2001
  • Laatst online: 09-07-2024

Alarmnummer

-= Tja =-

Eelke Spaak schreef op vrijdag 24 december 2004 @ 08:44:
[...]

offtopic:
Zo doe ik het ook met een project waarmee ik bezig ben. Je moet bij middlegen toch wel alle tabellen nog specificeren (of in ieder geval de many-to-many mappings)? Of zit dat er gewoon niet in omdat het een template is?
[quote]
Dat zit er nog niet in en je kunt die info ook opnemen in een extern bestand. Ik ben er ook nog (lang) niet klaar mee :)

Verwijderd

Topicstarter
Dit is natuurlijk al meer de richtig van verregaande automatisatie. Dit smaakt mij wel. Op dit moment ben ik vooral bezig met genereren van business logic op basis van eigen geschreven mapping file die dan op zijn beurt weer afgeleid is van de metadata van de database. Ook gui wordt gegenereerd naar xml die dan wordt omgezet door zelf gemaakt xml2gui voor swing. Eigenlijk had ik hier 2 maal een opensource project kunnen voor gebruiken (Hibernate en Sxixml) maar ja... voor schoolprojecten moet je zelf toch nog IETS programmeren!

In het boek "better smaller lighter java" wordt ook een transparante manier van persiting naar voren geschoven: gedaan met EJB, gedaan met de complexiteit. Welkom in de nieuwe wereld van lightweight frameworken die zwaar gebruik maken van reflection en codegeneratie.
Pagina: 1