1) Am I going in the right direction?
Questa è una domanda troppo ampia se si desidera che risponda con una quantità di dettagli. Non sappiamo esattamente quale sia la tua attuale esperienza e se ci siano cose che vale la pena imparare qui.
La lista che hai creato non sembra sbagliata a prima vista, ma ci sono molti modi in cui potresti sbagliare.
Ho visto innumerevoli sviluppatori seguire una certa struttura senza effettivamente capirne il fine (ad esempio separazione dei livelli e SRP) e finire per perdere pesantemente le loro astrazioni attraverso gli strati comunque. Lo stesso potrebbe accadere qui e non avrei alcun modo di sapere; quindi sono preoccupato di dirti che è decisamente buono.
2) Is it Okay not to use UnitOfWork while using Repository Pattern?
In breve : ho creato repository senza unità di lavoro prima, ma una volta che il codice arriva a qualsiasi livello oltre le semplici operazioni CRUD, ti pentirai di non aver implementato una UoW. Suggerirei di implementare una UoW a meno che tu non sappia per un fatto che la tua applicazione non gestirà mai alcuna logica o transazione complessa.
Il modello di repository ha un grosso svantaggio. Sto omettendo le preoccupazioni a livello di architetto e sto solo affrontando problemi al livello in cui sembri.
Il grande svantaggio dei repository è che hanno il loro datacontext . Questo non è un problema quando le tue operazioni sono sempre focalizzate su una particolare entità (o modulo di dominio), ma il problema diventa più rilevante una volta che inizi a lavorare con più tipi di entità contemporaneamente (ad esempio un rapporto complesso o un metodo di importazione che crea molti tipi di entità).
Prima di tutto, dove inserire il codice che recupera tutti gli oggetti Foo e i relativi oggetti Bar correlati? %codice%? %codice%? Troverai un sacco di disaccordo qui. Qualunque sia la posizione che scegli, alcuni sviluppatori si aspettano sempre che si trovi nell'altra posizione o sostengono che dovrebbe essere collocato in una terza posizione.
In secondo luogo, i repository (senza un'unità di lavoro) ti fanno perdere l'integrità transazionale tra diversi tipi. Supponiamo che tu abbia un'importazione che dovrebbe creare 3 oggetti (un FooRepository , un BarRepository e un Foo . Tuttavia, se una di queste azioni dovesse fallire, vuoi assicurarti che nessuno degli elementi vengono salvati.
Senza un'unità di lavoro, il tuo Bar avrà un datacontext diverso dal tuo Baz , il che porta a un'impossibilità di assicurare che entrambi gli elementi / nessuno siano salvati nel database.
Un'unità di lavoro, tuttavia, garantisce che tutti i repository (nello stesso oggetto uow) condividano lo stesso datacontext e pertanto è possibile mantenere l'integrità transazionale.
Esistono altri metodi per implementare l'integrità delle transazioni, ma sono spesso sporche e notevolmente inferiori all'implementazione di UoW.
3) I am really confused about Authentication. How should I authenticate my users and web api? Forms Authentication for users in my app? and token based for web api?
Dipende molto da ciò che stai cercando di realizzare. Chi saranno i tuoi utenti finali? Persone a caso? I dipendenti di una certa compagnia? È necessario che gli utenti effettuino l'autenticazione sull'app e non solo rendano l'app liberamente accessibile, ma blocchino tutte le informazioni dietro la stessa API? Richiede l'autenticazione offline e / o l'accesso alle risorse?
Non c'è una risposta qui. Questo ha bisogno di un lotto più spiegazione da parte tua e dovrebbe essere una domanda separata.