dunque, nello strato di presentazione devo fornire le seguenti funzionalità (azioni)

- lista dei prodotti filtrata per categoria
- aggiunta prodotto
- rimozione prodotto
- modifica prodotto

Detto ciò pensavo di creare una classe ProductService nel quale implementavo i seguenti metodi:

- Public Function GetProducts() as IQueriable(Of Product) ' e' coretto?? o meglio usare List(Of Product) ?

- Public Function GetProductsByCategory(byval cat as String) as IQueriable(Of Product) ' sarebbe meglio GetProductsByCategory(byval cat as Category) ' in questo modo si presume che lo strato UI conosca l'object model e di conseguenza l'entità Category.

- Public Sub CreateProduct(name, code, id_category, ecc..)

- Public Sub DeleteProductById(id as integer)

- Public Sub UpdateProduct(id_product, name, code, id_category, ecc..) ' uppure è sempre meglio creare una nuova entità nel code-behind della pagina aspx e passarla a tutti i metodi sopra citati??


Come affermato nel post precendete, ho aggiunto un nuovo progetto alla soluzione chiamandolo "ServiceLayer". Questo progetto conterrà i riferimenti verso il DAL (ovvero il progetto EntityFramework e verso il progetto "Common" che contiene le interfacce dei repository + l'object model con le classi POCO.

Aggiungo che le pagine aspx saranno delle web forms e non penso di utilizzare Dynamic Data o ObjectDataSource...

A te fileman, e a tutti voi, le considerazioni.

Grazie mille!

fileman ha scritto:

agguinta, aggiornamentose Common è comune, o il servizio espone un datamember uguale alla classe POCO, puoi usare direttamente la classe, non le singole proprietà

Questo passo non l'ho capito... :( cosa intendi per "datamember" ??
"Common" è comune e contiene il modello (file edmx + model.tt con classi generate dal template POCO di Entity Framework) + le interfacce dei repository (es: IPRoductRepository e IRepository)

Ciò mi consente di avere a disposizione in tutto il progetto i Tipi Product, category, ecc... direttamente generati dal template POCO di EF).

ObjectDataSource perchè non usarlo? Specie se hai servizi che espongono classi

Ok, allora è meglio che lo approfondisca sul manuale "ASP 4.0 in C# e VB" made in this site ;)

ASP.NET non è proprio il mio forte, e questo thread s'è allungato tanto, se non ricevi altri pareri, prova a farne uno nuovo ed usare un oggetto più preciso sul problema o dubbio dei metodi.

Si hai ragione, solo che come hai potuto notare i miei dubbi al momento riguardano l'architettura della mia applicazione e non un problema specifico... cerco ad ogni modo di fare meno affidamento in questo thred.


ps: Domanda stupida: perchè dovremmo usare IQueriable (inteso come interfaccia) e per List(Of...) invece non usiamo l'interfaccia ma il tipo?? Perchè non usare allora IList(Of...). Non ho capito il vantaggio o il motivo di usare alcune volte le interfacce come tipi e altre volte no. :)

---

Modificato da vailfox il 07 dicembre 2010 16.31 -

fileman ha scritto:

un servizio wcf è formato da OperationContract ed eventualmente DataMember, ossia Metodi esposti e tipo di dati trattato, guarda questo

Link molto interessante, lo approfondirò in serata...
ps: ma io non sto utilizzando WCF (anzi.. ancora non ho capito bene cosa sia...)

se usi l'interfaccia è meglio, per talmente tanti motivi che non saprei da dove iniziare e soprattutto non ho la competenza per entrare nei dettagli

Ma almeno i motivi più importanti potresti riassumerli??
Quando è meglio usare l'interfaccia di un tipo e quando invece no?


Altra domanda (mamma mia quanto sono palloso ), il metodo GetAll del mio ProductRepository mi ritorna un IQueriable(Of Product).

Quando uso quel metodo nell'implementazione del metodo GetAll del ProducService restituisco come tipo una List(Of Product).

Nel momento in cui eseguo la pagina aspx mi da l'errore "impossibile eseguire il cast tra List(Of Product) e IQueriable(Of Product) .... in questo caso sarebbe meglio modificare il ProductRepository in modo tale da far restituire al metodo GetAll una List(Of Product) apposto dell'IQueriable(Of Product) ?? o è meglio un'altra via??

---

Modificato da vailfox il 07 dicembre 2010 17.00 -

fileman ha scritto:

la corrispondenza tra tipi è sempre meglio, se vuoi esporre un IList o il servizio invia un IList, o aggiungi .ToList() al IQueriable

Ok adesso è più chiaro. Grazie!

Windows Comunication Foundation, o WCF, è la parte del framework per i servizi, assolutamente utilizzalo!!!

Dovrò studiare anche WCF! :)
Per il momento, visto la demo e lo scopo della mia applicazione ne posso fare anche a meno?? in fondo al momento devo creare un'anagrafica prodotti, una "distinta base di produzione" (non so se la conosci..?)

I più importanti ... mmm ... c'è un capitolo nel libro "ASP.NET 4.0 in C# e VB" che introduce benissimo il concetto

Nel libro l'interfaccia viene definita come "Tipo Astratto", non è molto chiaro il significato..., faccio una googlata ;)


GROSSO PROBLEMA!

Se dai uno sguardo al mio ProductRepository (qualche post precedente) noterai che ho implementato il metodo Include.

Ora, nel ProductService vorrei utilizzare l'include di quel reository per includere (fare uno join) con la tabella "Category" e far comparire nella mia GridView l'elenco prodotti e rispettiva categoria. La gridview è impostata con autogeneratecolumn = true.

Ma è sbagliato l'uso che faccio dell'include??




Come mai?? Quella include nasce per includere a sua volta un'altro ObjectSet di tipo product ??
Ho implementato quel repository prendendo ad esempio ModelVC...