Qui utilise ce type d'appli ?
Est-ce toujours disponible dans les dernières versions de delphi ?
Version imprimable
Qui utilise ce type d'appli ?
Est-ce toujours disponible dans les dernières versions de delphi ?
Tu as l'équivalent, Delphi Prism qui est vraiement .NET,
Je ne connais pas la VCL.NET mais il me semble que ce n'est plus compatible !
en même temps, :google: confirme !
Does Delphi Prism include support for VCL.NET?
No. Development for VCL.NET has been deprecated and will not be supported in Delphi Prism. Developers using VCL.NET can either use Delphi 2007 to continue those products or can migrate their VCL.NET applications to VCL for Win32.
C'est malheureusement ce que je viens de voir ...
Comme c'était aussi simple que ca de migrer son code en vcl win32
Entre ca et ECO qui ne suit plus non plus ... que des bonnes nouvelles :(
en même temps je ne comprend pas bien l'intérêt de faire du .Net avec Delphi...la VCL n'a pas besoin de .Net et .Net n'a pas besoin de la VCL...enfin c'est mon avis que je partage avec moi même :)Citation:
Envoyé par RamDevTeam
VCL.NET permettait de continuer à développer comme en version win32, tout en bénéficiant des fonctionnalités .net
L'idée était prometteuse.
Quand BDS2005 est sortie, une des grandes nouveautés à mon sens étaient la possibilité d'utiliser un framework O/R.
2 possibilités pour cela :
- VCL.NET
- Delphi.Net
Quand on a des composants tiers uniquement dispo pour la VCL on n'a pas tellement le choix. il faut s'orienter vers VCL.NET
Le gros problème =>
ECO II apparaît en D2005, est amélioré avec BDS2006 (ECO III) ,puis est supporté avec RAD Studio 2007( ECO IV) (mais la licence n'est plus incluse à cause de la séparation vers CapableObject) puis tout s'arrête.
C'est la première fois depuis que j'utilise delphi que la migration vers une version plus récente entraine autant de travail de réécriture ...
La seule solution pour actualiser une application VCL.NET + ECO ... c'est refaire TOUT les accès aux données pour repartir vers une gestion type Dbexpress.
un exemple simplifié.
Pour connaitre l'adresse de livraison d'un client pour un commande
Code:
2
3
4
5
6
7
8
la même chose sans ECO =>
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Je ne parle même pas du pilotage office via les assemblys .net qu'il faut également refaire.
je ne connais pas ECO (uniquement Umberto) mais il est possible de créer les classes nécessaire à la compilation du premier code au lieu de tout réécrire.
alors j'imagine que ECO permet de maintenir ces classes en fonction des modifications de la BDD ...sinon à quoi sert-il ?...mais si tu estimes que cette approche est la meilleur, il est possible de le faire en pur Pascal, ce qui m'a toujours semblé être la meilleur solution. Car du pur Pascal se compile aussi bien sous W32 que sous .Net (et autre avec FreePascal) :)
Effectivement avoir des classes à l'identique du modèle ECO n'est pas très compliqué à faire pour ce qui concerne les propriétés et une partie de la génération du code peut être automatisé à partir des metadata de la base de données. je vais fouillé dans mes archives, j'avais fais un petit dév la dessus.
Par contre les associations sont complétement à recoder puisque les associations déclenchait de manière transparent des requêtes sur d'autre table
Les requêtes OCL sont à transformer en requête SQL.
Les héritages de classes sont également à réadapter.
C'est loin d'être impossible, mais il y a énormément de boulot.
moi j'aimerai bien pouvoir déclarer mes bdd en Pascal :)
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18database abonnes = table id : index; name : string[25]; password : string[16]; create_date : TDateTime; last_login : TDateTime; end; article = table id : index; owner : ^abonnes.id; title : string[30]; create_date : TDateTime; description : TMemo; price : Currency; end;
C'était pas Bold sous D7 qui permettait de la faire par hasard :)