Progetti MVC e Web API nella stessa soluzione

Ho creato una soluzione qualche tempo fa che contiene un progetto Web API 2 (fornisce dati JSON ai dispositivi mobili) e una libreria di classi (include i miei servizi di accesso ai dati).

Il progetto API Web utilizza Ninject per DI e tutto funziona correttamente.

Ora ho bisogno di aggiungere un progetto MVC separato per alcune pagine web. L’API dovrebbe essere accessibile da www.example.com/api/controller , mentre il sito web dovrebbe essere accessibile attraverso www.example.com/controller .

Il problema è che ognuno di questi due ha un diverso metodo “Registrati” con raccolte di percorsi apparentemente incompatibili. Se imposto il progetto MVC come progetto di avvio, i percorsi per l’API non sono registrati e viceversa. Se imposto “Mutiple startup projects”, funzionano su porte diverse che non sono la mia tazza di tè.

Come posso impostare il progetto MVC come progetto di avvio, mentre registro tutti i percorsi per entrambi?

Un’altra cosa. Poiché il progetto API Web è stato creato prima, la configurazione di Ninject è stata scritta al suo interno. Naturalmente, alcuni dei servizi del progetto Class Library sono necessari all’interno del nuovo progetto MVC. Devo spostare la configurazione di Ninject nel progetto MVC, o funzionano solo perché vengono eseguiti all’avvio del progetto Web API?

Questi 2 progetti sono indipendenti l’ uno dall’altro come 2 diverse applicazioni, anche se si trovano nella stessa soluzione .

Per riuscire in quello che cerchi di raggiungere, devi:

1) Distribuisci il tuo progetto MVC su www.example.com ( applicazione virtuale principale).

2) Distribuisci il tuo progetto WebAPI su www.example.com/api (la cartella api è un’applicazione virtuale ). Non dimenticare di rimuovere api dalle tue rotte WebAPI (altrimenti devi usare questa rotta www.example.com/api/api/controller ).

In questo modo puoi accedere indipendentemente a entrambi i progetti nello stesso URL .

Per la parte NInject, è ansible registrare nuovamente i servizi nel progetto MVC. Un’altra soluzione (che raccomando) è quella di creare un progetto di libreria di classi e registrarvi i servizi dopo aver fatto riferimento a questa libreria di classi in entrambi i progetti.

Quello che mi piace fare è avere il progetto MVC e WebAPI in due progetti separati ( separazione delle preoccupazioni ) ma lasciare che condividano la stessa logica di business.

Mi piace utilizzare il modello Command and Query. Quindi tutti i comandi e le query si trovano in un altro progetto di soluzione a cui hanno accesso sia il progetto MVC che WebAPI.

Distribuisco il progetto MVC sul percorso www.domain.com , il progetto WebAPI su api.domain.com e abilita CORS su WebAPI per l’origine www .