Consulenza per quanto riguarda la modifica di NetTiers

Question

Sto usando assesing NetTiers per il mio prossimo progetto.

Il problema è: Ogni tavolo nel mio schema ha un accountid campo. Con ogni richiesta al DAL io voglio che sia un requisito che l'AccountID è passato e utilizzato come filtro nella query.

Sarebbe accettabile se un sovraccarico aggiuntivo è stato generato che ha usato questo paramater.

Ho il sospetto che questa funzionalità non è costruita in modo chiunque può offrire qualche consiglio su dove cominciare con la modifica dei modelli per inserirlo?

Answer 1

Modifica dei modelli NetTiers non è difficile una volta che tipo di conoscere il modo per aggirare il labirinto di classi che genera, ma di solito è abbastanza noioso e molto soggetto ad errori.

La mia prima ipotesi è che il database si sta generando off è o ha solo pochi tavoli o è denormalizzato - altrimenti non avrebbe senso avere un accountid colonna in ogni tabella. Se è il più tardi e la struttura non può essere normalizzato, che credo che sarebbe un cambiamento abbastanza pesante per ottenere tutte le it proprietà di navigazione costruiti sulla base del database chiavi esterne (compresi DeepLoads) che lavorano con un extra di accountid filtro.

Inoltre, è ricordare che sovraccarichi aggiungendo contenente accountid sarebbe una soluzione accettabile. Tuttavia, questo lascerebbe i sovraccarichi NetTiers esistenti che non richiedono un accountid parametro per eventuali consumatori DAL ...

In ogni caso, ecco un riassunto di alcune delle aree si avrebbe bisogno di esaminare la modifica:

• Per assicurarsi che nessuna query può essere eseguito con successo senza fornire un accountid (ci sono molti modi per aggirare il DAL predefinito tramite la clausola GetPaged @where per esempio), si avrà probabilmente necessario apportare modifiche a livello di SQL. Questi modelli si trovano nelle cartelle /DataAccessLayer.*Client/. Supponendo che si sta utilizzando il server SQL, il file che genera il codice SQL ( /DataAccessLayer.SqlClient/ StoredProcedureProvider.cst) potrebbe essere modificato per garantire un parametro @AccountId viene sempre passato.

• Questo porterà a cambiamenti nei file correlati come /DataAccessLayer.SqlClient/SqlEntityProviderBase.generated.cst e /DataAccessLayer/EntityProviderBaseCore.generated.cst e, probabilmente, /DataAccessLayer/EntityProviderBaseCoreClass.generated.cst .

• Questo a sua volta portare a cambiamenti nel livello entità ( /Entities/ ) quali EntityBaseCore.generated.cst e EntityInstanceBase.generated.cst.

Il mio consiglio generale è che, mentre NetTiers e CodeSmith erano strumenti di scelta per la costruzione di dals a pochi anni fa, non ho potuto consiglio di andare su questa strada in questi giorni. Con l'evoluzione della Entity Framework del Microsoft e open-source NHibernate, non si dovrebbe davvero bisogno di dilettarsi troppo in profondità nello strato di accesso ai dati idraulico più (anche se solo a livello di codice-generazione).