Come progettare una funzionalità per condividere il contenuto?

I want to know if this is the correct way to implement a functionality like this? Is there any other way?

OK finora (date le informazioni limitate) ma il design è incompleto quindi non direi che è assolutamente corretto. Progettare la funzionalità, il design della classe. Quando hai tutti i requisiti coperti, guarda nel database in dettaglio.

Non sto dicendo che non pensare al database. Ma dovresti progettare le classi e le loro interazioni. Questo informerà la progettazione del database; non dovrebbe essere il contrario.

Cerco di pensare al database come "un dettaglio di implementazione". In altre parole, il database specifico e i suoi dettagli sono sostanzialmente irrilevanti per il design della funzionalità di classe.

Buona domanda, ma non esiste un unico, un modo per dominarli tutti per implementare questa "condivisione". Quello che hai selezionato dovrebbe funzionare.

L'unico lato negativo che vedo è: "Cosa succede quando una risorsa ha bisogno di più di un gestore"

Ma ancora una volta, tutte le implementazioni avranno un inconveniente o un altro. Vorrei iniziare con questo e non pensarlo fino a quando non si incontra un vero problema.

Il tuo design sembra soddisfacente, ma credo che ci sia un modo per migliorarlo rendendolo più astratto.

A quanto ho capito, fai la differenza tra la gestione di un contatto e la visualizzazione di un contatto. Questa differenza porta anche a un comportamento diverso:

• Nel caso di gestione di un contatto, (1) una sola persona può (2) modificare e condividere un contatto,

• Nel caso di visualizzazione di un contatto, (1) zero o più persone possono (2) visualizzare, ma né modificare, né condividere un contatto.

Sembra un sistema basato su permessi, con un read, write-write e allow-other-to-read su un oggetto, con una differenza: il numero di persone che potrebbero essere assegnate ai ruoli, dal momento che abbiamo impostato un limite arbitrario di 1..1 per il permesso di scrittura, bloccando ulteriormente la possibilità per due utenti di gestire un contatto.

A parte questo particolare dominio aziendale, non sarebbe sensato che due utenti gestiscano un contatto, non dovresti farlo.¹ Ciò che è importante non sono alcune considerazioni tecniche arbitrarie, come "Ma come gestirò un caso in cui due persone modificano lo stesso contatto nello stesso momento? "Ciò che è rilevante è esclusivamente il dominio aziendale.

La copia dello schema delle autorizzazioni comporterebbe un insieme leggermente diverso di tabelle. Avrai ancora Users e Contacts , ma ora avrai anche una tabella Roles e una tabella Permissions che garantirebbe un ( n .. < em> n ) relazione tra le precedenti tre tabelle, il che significa che saresti in grado di impostare in una singola tabella una relazione come:

User 123 has a permission read-write on contact 456.

^{¹ Posso immaginare un sistema medico che è stato originariamente progettato con un concetto centrale che una cartella clinica del paziente può essere gestita solo dal suo medico. Questo potrebbe mostrare rapidamente i suoi limiti, poiché non è insolito che un dottore lavori congiuntamente con un collega, o abbia un tirocinante, o venga temporaneamente sostituito da un altro dottore.}