Ciao,
puoi certamente crearti un altro progetto class library in cui metti il tuo BLL, come hai sempre fatto.
Non è detto che tu debba esporre le entità del tuo modello con ASP.NET Web API, anzi, possono essere dei DTO che poi rimappi opportunamente sulle classi del tuo modello.

Se scegli per questa strada ti troverai con una certa quantità di codice di plumbing per ricondurre le action del tuo ApiController ai rispettivi metodi CRUD nel tuo BLL. Vale la pena farlo? Probabilmente no se le entità del tuo modello sono anemiche (non hanno logica) e rimappano 1:1 con il rispettivo DTO.

Dico questo perché ASP.NET Web API, essendo una tecnologia per realizzare API RESTful, viene usato spesso (ma non sempre) come backend per applicazioni orientate ai dati, ovvero che hanno delle maschere di visualizzazione, inserimento e modifica. In questo caso la logica è limitata all'autorizzare i client in base al loro ruolo.
Ripeto: non sempre. La tua applicazione come funziona? Quando ricevi una POST come ti comporti, devi inserire quei dati nel database così come sono?

ciao,
Moreno

Ciao, prego!

simonepenna ha scritto:

Capisco che questo modo di programmare è molto spinto per il lato client e quindi forse non vale la pena fare la parte BLL separata.

Sì, dipende che utilizzo fai della Web API: per esempio potrebbe essere il Data Access Layer di un'applicazione distribuita e quindi comprendi che mettere un BLL lì dentro potrebbe non essere necessario. Alla fine, l'esistenza di un componente (o di un intero strato) deve sempre essere giustificata dal valore che apporta all'applicazione nel suo complesso.

Studia anche altri pattern architetturali, non è detto che la n-layered architecture sia la più adeguata in ogni caso.
Guarda per esempio questi estratti del team Patterns & Practices di Microsoft, sono letture interessanti (specialmente la parte 3 che introduce i vari stili).
https://msdn.microsoft.com/en-us/library/ee658098.aspx

simonepenna ha scritto:

- progetto.BUSINESS (dove risiedono le WebApi con controller OData)

Perché mettere la logica di business in un progetto a sé stante? Perché, teoricamente, devi poi poterla portare e riutilizzare col minimo sforzo su più tipi di applicazione (web, windows, altro).
Spesso però devi scendere a patti con quello che ti permette di fare la tecnologia attuale, infatti non riuscirai ad installare il pacchetto di WebAPI in un progetto Portable Class Library e quindi questa portabilità viene meno.
La cosa però cambierà presto perché da ASP.NET MVC 6 (tecnologia unica che include anche la prossima versione di Web API), i tuoi Controllers possono essere delle classi POCO e le puoi facilmente inserire in un progetto Portable Class Library dato che non avranno dipendenze. In quel caso tenere i Controller nel progetto Business non incontra particolari ostacoli.
http://www.strathweb.com/2014/06/poco-controllers-asp-net-vnext/

simonepenna ha scritto:

Cosi se volessi aprire u servizi come webService sarebbe un gioco da ragazzi e il codice cosi facendo è molto centralizzato.

Sì, o qualsiasi altro tipo di frontend.

ciao,
Moreno

---

Modificato da BrightSoul il 10 dicembre 2015 19.47 -