CodeFluent – Procédures stockées

CodeFluent – Procédures stockées

CodeFluent repose énormément pour ne pas dire uniquement sur les procédures stockées

Il est possible de définir dans les fichiers Xml de définition des entités ses propres procédures stockées …

Je crée 2 procédures (celles –ci sont placées dans le « corps » de l’entité concernée, ici Contact):

-          FindFirstStartsWith retournera 1 objet contact(>loadone)

-          FindAllStartsWith retournera une collection de contacts (>load)

On peut définir les contraintes des paramètres avec la balise <cf :parameter/>

<cf:project xmlns:cf="http://www.softfluent.com/codefluent/2005/1"

                  xmlns:cfpc="http://www.softfluent.com/codefluent/producers.cache/2005/1"

                  defaultNamespace="CFContacts"

                  persistencePropertyNameFormat="{1}"

                  defaultKeyPropertyTypeName="int">

 <!-- inclut le fichier CFContactsProducerAll.xml -->

 <cf:importpath="CFContactsProducerAll.xml" />

 <!-- definition de 2 entités -->

 <Contact>

    <Id/>

    <ContactName/>

    <ContactFirstName/>

    <ContactAge typeName="int"/>

    <ContactBirth typeName="datetime"/>

    <ContactCategory typeName="ContactCategory"/>

    <cf:method name="FindFirstStartsWith" body="loadone where ContactName Like @start" >

      <cf:parameter name="Start" nullable="false" />

    </cf:method>

    <cf:method name="FindAllStartsWith" body="load where ContactName Like @Start" >

      <cf:parameter name="Start" nullable="false" />

    </cf:method>

 </Contact>

 <ContactCategory>

    <Id/>

    <ContactCategoryLabel/>

 </ContactCategory>

</cf:project>

Les 2 procédures stockées correspondantes générées

CREATE PROCEDURE [dbo].[Contact_FindAllStartsWith]

(

 @Start [nvarchar] (256),

 @_orderBy0 [nvarchar] (64) = NULL,

 @_orderByDirection0 [bit] = 0

)

AS

SET NOCOUNT ON

SELECT DISTINCT [Contact].[Id], [Contact].[ContactName], [Contact].[ContactFirstName], [Contact].[ContactAge], [Contact].[ContactBirth], [Contact].[ContactCategory_Id], [Contact].[_trackLastWriteTime], [Contact].[_trackCreationTime], [Contact].[_trackLastWriteUser], [Contact].[_trackCreationUser], [Contact].[_rowVersion]

    FROM [Contact]

    WHERE ([Contact].[ContactName] LIKE @Start)

RETURN

GO

CREATE PROCEDURE [dbo].[Contact_FindFirstStartsWith]

(

 @Start [nvarchar] (256)

)

AS

SET NOCOUNT ON

SELECT DISTINCT [Contact].[Id], [Contact].[ContactName], [Contact].[ContactFirstName], [Contact].[ContactAge], [Contact].[ContactBirth], [Contact].[ContactCategory_Id], [Contact].[_trackLastWriteTime], [Contact].[_trackCreationTime], [Contact].[_trackLastWriteUser], [Contact].[_trackCreationUser], [Contact].[_rowVersion]

    FROM [Contact]

    WHERE ([Contact].[ContactName] LIKE @Start)

RETURN

GO

Bien entendu on a deux méthodes bien pratiques ajoutées à la couche métier

 

Le choix de l’utilisation de IList,ICollection à la place des generics permet certes l’utilisation du projet en .NET 1.0 mais on ne dispose pas des méthodes de filtre très pratiques (Find,FindAll)

Plusieurs solutions sont alors possibles :

-          Soit créer ses propres méthodes de filtre qui répondront au besoin

-          Soit créer des méthodes recevant un predicate

C’est donc une grosse erreur, espérons qu’à l’avenir les generics seront utilisés, car avec .NET 3.0, on risque de ne même pas pouvoir utiliser les requêtes Linq To Objects