Ciao,

rubinim ha scritto:

volevo sapere se questo metodo era corretto e se era corretto creare questa classe nel layer Models visto che è quello visibile da tutti i livelli

Beh, sì, quella classe deve necessariamente trovarsi in un progetto referenziato sia dalla UI che dal Service, altrimenti la compilazione fallirebbe.

Ora dovrei capire se quella classe contiene proprietà o metodi rilevanti solo per la UI. Ad esempio, se avesse delle dipendenze da System.Web, non sarebbe troppo corretto posizionarla nel progetto Models perché così ne limiterebbe la portabilità (cioè introdurresti dipendenze che non hanno senso in applicazioni non web).

Quel che potresti fare, quindi è inserire nel progetto Model sono un'interfaccia, da chiamare ad esempio IFilter e, a quel punto, i metodi del Service layer accetterebbero argomenti di tipo IFilter.
Nel layer della UI saresti quindi libero di creare varie implementazioni di IFilter e di legarli a doppio filo con la UI, se vuoi.

Qui però il discorso si fa un po' astratto perché non conosco come sono fatti questi filtri e come il service layer va ad usarli.

Potresti anche usare delle Func<entita, bool> (un po' come si usa in Entity Framework e Linq to Objects) anziché costruirti delle nuove classi. Però non so darti un consiglio preciso non conoscendo bene il tuo scenario.

ciao,
Moreno

---

Modificato da BrightSoul il 03 settembre 2015 22.07 -

Ciao, scusami avresti al possibilità di farmi un'esempio della soluzione creando l'interfaccia IFilter.

Ciao eGrazie in anticipo se possibile.

Grazie

Ciao,

In questo caso è dal livello repository che dovrei richiamare il

Direi di no perché il repository ha una sola responsabilità molto specifica: recuperare entità dallo storage e persisterle quando vuoi salvare i cambiamenti. E' un servizio infrastrutturale che si occupa di traghettare i dati tra il modello relazionale e quello ad oggetti.

Tutte le logiche di filtraggio potresti inserirle nello strato dei servizi applicativi, che contengono invece - tra le altre cose - la logica con cui vai ad interrogare il repository.

Ora c'è un problema da risolvere: l'articolo che hai linkato propone un'implementazione di IRepository che non espone mai degli IQueryable, ma degli IEnumerable. Guarda per esempio la firma del metodo GetAll


E questo non ti mette in grado di usare la mia implementazione di IFilter, che invece lavora proprio con degli IQueryable.


Ora bisogna decidere se preferisci modificare l'implementazione del repository o l'implementazione di IFilter.

Nel primo caso, si tratta di far restituire IQueryable<DocTe> al metodo GetAll(), ammesso che sia possibile. Come stai persistendo i dati nel db? Entity Framework?

Nel secondo caso, bisogna che IFilter esponga una proprietà di tipo Expression<Func<T, bool>> che potrai passare al metodo GetMany del repository.

E' abbastanza facile fare questa modifica perché la mia implementazione di IFilter già lavora internamente con Expression<Func<T, bool>> (che è l'espressione di filtraggio) e basta tirarla fuori come vedi qui.
https://dotnetfiddle.net/vjbnjE

ciao,
Moreno

---

Modificato da BrightSoul il 06 ottobre 2015 20.45 -