Ci è stato assegnato il compito di creare uno strumento di flusso di lavoro basato sul web per tenere traccia della gestione delle modifiche. Ha un unico flusso di lavoro con attività sincrone multiple per la maggior parte, ma si dirama in un punto verso le attività in parallelo che si incontrano più tardi. Ci saranno molti tipi di persone che usano l'applicazione, e tutti dovranno vedere i loro compiti in sospeso per ogni cambiamento, ma solo i loro, non altri. Ci sarà anche un gruppo di persone di alto livello che supervisionerà tutti i cambiamenti, quindi è necessario vedere tutto. Dovranno vedere compiti che non sono stati eseguiti nel tempo specificato, chi è responsabile ecc.
I dati verranno mantenuti su un database SQL. Sarà tutto messo insieme usando .Net.
Ho cercato di imparare e implementare OOP nei miei progetti fino a tardi, ma mi chiedo se questo è discutibile in questo caso, perché potrebbe essere meglio avere la logica aziendale per questo nelle stored procedure nel DB. Potrei usare POCO, un front-end layer e un livello di accesso ai dati per l'applicazione web e usarlo come meccanismo per le azioni CRUD sul DB, quindi utilizzare gli SP licenziati nel DB per applicare le regole aziendali.
D'altra parte, potrei usare un design orientato agli oggetti all'interno dell'app web, ma dato che i dati nell'app non hanno lo stato, è una cattiva idea? Potrei provare a modellare l'intera applicazione in una struttura di classe, implementando interfacce, classi base e tutte quelle cose buone. Quindi creo una classe di modifica, che contiene un elenco di classi / tipi di attività, che definiscono ciascuna attività e implementa un'interfaccia ITask, ecc. Metti i tipi di utenti finali nelle attività per identificare chi dovrebbe svolgere il compito. Quindi applica tutte le logiche di business nei rispettivi metodi di classe ecc.
Quale approccio pensate che dovrei usare per questa soluzione?