Domanda

Ogni oggetto business ha un oggetto corrispondente che contiene chiamate sql. Vorrei limitare questi oggetti sql in modo che possano essere utilizzati solo dall'oggetto business corrispondente. Come è possibile raggiungere questo obiettivo?

Aggiorna

Greg ha sollevato il punto sulla testabilità. Poiché SqlObjects conterrà sql molto specifico per il processo aziendale, non li voglio riutilizzare in più oggetti di acquisto. (Le operazioni CRUD di base sono tutte generate dal codice) Esiste un modo per rendere SqlObjects accessibile a un solo oggetto business nell'assemblaggio aziendale (come mostrato da yshuditelu e Greg Beech) E esporre SqlObjects all'assemblaggio di test unitari?

È stato utile?

Soluzione

Se questo è l'approccio che si desidera o è necessario adottare, è possibile rendere gli oggetti sql classi private all'interno dell'oggetto business.

public class BusinessObject
{
    private class SqlObject { }
}

Inoltre, facendo uso di classi parziali, è possibile separarlo in file separati, se desiderato.

//in one file
public partial class BusinessObject
{
    //business object implementation
}

//in another file
public partial class BusinessObject
{
    private class SqlObject { }
}

Joel fa un buon punto in un commento sotto " lo SqlObject può ancora ereditare da un tipo comune, a cose come le informazioni sulla connessione possono essere condivise tra quelle "interne" . Classi " questo è assolutamente vero e potenzialmente molto utile.

In risposta alla tua modifica, i test unitari possono solo testare classi e funzioni pubbliche (senza usare la riflessione nei test). L'unica opzione a cui riesco a pensare sarebbe:

  • crea un assieme per coppia di oggetti business / sql
  • modifica del classe privata SqlObject in classe interna SqlObject
  • quindi utilizza [InternalsVisibleTo (" UnitTestsAssembly ")] per il progetto

Inoltre, a questo punto non dovresti tenere l'oggetto sql come una classe nidificata. In generale, penso che ciò aggiungerebbe probabilmente più complessità del valore che aggiunge, ma capisco perfettamente che ogni situazione è diversa e se i tuoi requisiti / aspettative ti stanno guidando, ti auguro ogni bene. Personalmente, penso che vorrei andare a rendere pubblici gli SqlObjects (o interni con interni visibili per i test unitari) e accettare il fatto che ciò significa che le classi sql sono esposte a tutte le business class.

Altri suggerimenti

L'unico modo per farlo è rendere l'oggetto SQL un tipo nidificato privato, ovvero

public class BusinessObject
{
    private class SqlObject
    {
    }
}

Se questa è una buona idea dal punto di vista della testabilità è un'altra cosa del tutto ...

Stai tentando di implementare una classe Friend in C ++. Per quanto ne so C # e VB.Net non hanno nulla di equivalente. Il mio unico suggerimento è di rendere la classe che desideri limitare una classe interna della classe che deve accedervi.

Puoi anche lavorare con due assembly (uno per gli oggetti business e uno per i relativi oggetti SQL) e usare il modificatore interno su ogni classe SQL e usare quindi [InternalsVisibleTo (" BusinessObjectAssembly ")] per SQLAssembly.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top