Blog Michel Lévy

En lisant VFP Advisor, je suis tombé sur une publicité qui m'a semblé intéressante : STRATAFRAME...

Je suis allé voir le site, et évidemment, j'ai tout de suite repéré la page d'accroche pour les développeurs VFP.

Et bien évidemment, j'ai tout lu, regardé les vidéos de présentation, téléchargé la version d'essai, et.... je vais commander ce framework.

C'est quoi, Strataframe ? C'est un framework pour VB.NET ou C# centré sur les données. En deux mots (j'en reparlerai plus longuement), ça vous met à disposition des objets métiers qui sont très proches des cursoradapter de VFP (mais on peut avoir autant de requètes SQL qu'on veut dans le même objet), et ça offre le databinding aux controles des Winforms de .net.

Allez, on en reparle plus tard, mais pour moi, c'est choisi, Strataframe sera ma solution de migration.

DeleteCurrentRow(OnlyMarkAsDeleted) - When OnlyMarkAsDeleted is given a value of True, the current row is deleted within the internal data table only and a Save() must be executed before the changes are reflected back to the server.  This is recommended when deleting a large number of records.

et ça, est-ce que ça n'est pas parfois utile?

Dynamic Foreign Key Management - This feature is the most important - and most convenient - parent-child relationship element.  By establishing a relationship between parent and child, the foreign key can be automatically managed, thereby negating the need for the developer to manually track and update child records.  Additionally, new child records can be created on top of a new parent record without requiring an existing parent record.  When a new child record is created, the foreign key field will automatically be set to the value of the primary key of the parent business object.  When saved, the keys will be automatically cascaded from the parent record to the children records.

Allez, je continue de préparer mes valises pour ma migration, la suite de mes découvertes un autre jour...

Ouff!

ça n'a pas été facile, mais ça commence à venir.

En VFP, j'ai l'habitude d'avoir sur mon serveur SQL une base de données de paramétrages de l'application, qui permet entre autres choses de choisir le "dossier de travail", c'est à dire la base de données qui contient les datas vraiment utilisés dans l'application (ce qu'on faisait avant avec des dbf dans des répertoires différents).

Faire ça en VFP sur SQL Server, c'est facile (il suffit d'une propriété dans le form de premier niveau, qui stocke la connectstring qui sera utilisée dans le SQL Pass-Throug ou dans les vues).

Et en VB.NET??

J'ai mis 3 semaines à comprendre comment faire , et heureusement que le forum strataframe est réactif... Mais ça y est, j'y suis enfin arrivé:

MicroFour.StrataFrame.Data.DataLayer.DataSources.Remove("")

_cnxString = "Data Source=localhost;Initial Catalog=databcuv" & _DBstring & ";Integrated Security=True;Persist Security Info=False;Asynchronous Processing=True"

Dim cnxCuv As New MicroFour.StrataFrame.Data.SqlDataSourceItem("", _cnxString)

MicroFour.StrataFrame.Data.DataLayer.DataSources.Add(cnxCuv)

 

Vous aurez compris que la variable _DBstring contient une chaine qui complète "databcuv" pour pointer sur le bon database.

Mais surtout, surtout, vous aurez repéré ce DataLayer, qui est au coeur de StrataFrame!

 

A partir de là, construire une appli multi-dossiers multi-sociétés n'est guère plus complexe qu'en VFP, et ça, c'est la bonne nouvelle d'aujourdhui.

 Le problème de .NET, c'est qu'on a l'impression que ceux qui l'ont conçu ont juste oublié un petit détail : il ne suffit pas d'accéder aux données pour les lire, il faut aussi pouvoir écrire, les modifier , en ajouter, les supprimer...

Et là, les choses se compliquent : déjà qu'il faut 3 objets pour accéder aux données, quelle propriétés/méthodes utiliser dans lesquels de ces objets pour faire un update qui gère les conflits?

les forums .net sont pleins de ces questions-là, et les réponses sont aussi tordues les unes que les autres, et chaque réponse ne fait que prouver l'inadaptation complète de ces langages à cette problématique.

Alors, j'attendais StrataFrame au tournant, parceque pour moi, c'est un point capital, cette question de la gestion des conflits.

Créer un form simple de gestion des données, c'est rapide et facile en quelques drag and drop, que ce soit avec ou sans Strataframe.

Mais pouvoir choisir le mode de mise à jour "OptimisticAllFields" , "OptimisticTimeStamp" ou "OptimisticRowVersion", avec ou sans transaction, là, c'est du StrataFrame 100%!

Et pouvoir faire ces choix différemment pour Insert, Update, ou Delete, là, c'est le luxe!

Et pouvoir choisr de le faire au niveau de la classe  (ce qu'ils appellent un assembly) de l'objet d'accès aux données ou au niveau du form lui-même, c'est encore mieux que mieux.

Je n'ai pas encore essayé de passer par des procédures stockées sur le serveur, mais c'est aussi une option proposée : encore une fois, rien que du connu pour un développeur VFP/SQL.

Cerise sur le gâteau, si on a un retour d'erreur (que ce soit sur un doublon ou sur un conflit de mise à jour), on a le choix entre intercepter l'erreur pour la traiter soi-même ou laisser StratFrame gérer sur la base de messages personnalisables (et localisables pour une appli multilingue).

Les messages apparaissent au bon endroit, les champs incorrects en saisie sont bien pointés à l'utilisateur, ou bien un form est affiché qui propose le choix entre les valeurs actualisées depuis le serveur ou celles que l'utilisateur a saisies.

Allez, j'y retourne, je n'ai pas encore réussi à afficher ce form de choix exactement là où je voudrais, et il faut aussi que je trouve où on le localise en français.