Hai assolutamente ragione nel pensare, sì, devi assolutamente tenerli separati.

Tuttavia, non è necessario essere così difficile come si potrebbe pensare, al fine di ottenere il corretto funzionamento del layout su più dispositivi.

Realisticamente, hai 3 approcci che sono considerati pratica moderna in questa arena.

1) Creare un sito satellite per ciascuna piattaforma che si desidera supportare, quindi in un singolo controller dell'indice semplice, annusare l'agente utente e reindirizzare al sito satellite appropriato.

2) Utilizzare le query multimediali. Il supporto di Media Query è ora (ed è stato per un po 'di tempo) abbastanza buono e sufficientemente supportato da poter essere utilizzato nei siti di produzione completi.

3) Utilizza un toolkit UI come KnockoutJS o Angular e modifica i nomi delle classi e gli attributi sui tuoi layout in tempo reale, rispondendo alle modifiche degli user agent.

Più in dettaglio

Se decidi di andare con opzione 1 , la prima cosa di cui devi essere a conoscenza è il lavoro extra.

Essenzialmente, manterrai due siti.

Il tuo back-end tuttavia dovrebbe probabilmente rimanere lo stesso. Se utilizzi un design classico nTier con una radice di composizione SOLID, il tuo livello aziendale, il livello dati ecc. Possono essere tutti condivisi, quindi la manutenzione di siti secondari separati diventa molto più semplice.

Opzione 2 d'altra parte, significa che continui a mantenere un solo sito, ma lo svantaggio che hai qui è di complessità.

Per utilizzare correttamente le query multimediali, devi progettare il tuo sito per un'unica piattaforma, solitamente desktop, quindi devi decidere quali regole desideri sovrascrivere e per quale larghezza dello schermo.

Sebbene questo non stia modificando rigorosamente il tuo sito in base allo user agent, stai ancora adattando il tuo layout a una determinata larghezza dello schermo, il che significa che su schermi più stretti (come un dispositivo mobile) stai mantenendo un'uscita leggibile, mentre solo dover modificare l'importo minimo necessario per mantenere tale leggibilità.

Questo tende ad essere il percorso che molti dei CMS prendono, in particolare i progetti di wordpress, perché richiede pochissimo codice e tutto può essere modificato direttamente nel CSS.

Tuttavia, sei limitato a cambiare solo ciò che può essere cambiato usando i CSS, e poiché c'è ancora un bel po 'di instabilità nelle specifiche CSS3, potresti scoprire che devi ancora limitare alcune delle modifiche che desideri fare.

Questo mi porta a Opzione 3 (questa è la mia opzione preferita) e al modo in cui lavoro per la maggior parte di ciò che faccio.

Disegna semplicemente il layout come un tipo di layout universale, che sebbene non sia bello, funziona genericamente sulla maggior parte dei dispositivi.

Quindi, collega il tuo toolkit UI preferito. (Per me questo è KnockoutJS mixato con Twitter Bootstrap).

Usa il tuo kit di strumenti dell'interfaccia utente per riempire le parti dinamiche del tuo layout, sulla base di un endpoint di riposo che annusa l'UA dalla richiesta.

Ad esempio. nel mio CSS potrei avere:

.rule_for_desktop
{
  color: blah;
  width: blah;
}

.rule_for_iphone
{
  color: blah;
  width: blah;
}

.rule_for_android
{
  color: blah;
  width: blah;
}

e nel mio modello di vista per knockout potrei avere:

var cssRule = ko.observable("rule_for_desktop");
// More code for the rest of the VM here

e nel mio HTML (basato sul knockout) potrei avere

<div id="myElement" data-bind="css: cssRule">... some content</div>

Quello che succede allora è il mio layout predefinito per un layout desktop (o qualsiasi altra cosa che ho impostato come predefinito nel mio viewmodel.

Se poi sparo una richiesta AJAX, o eseguo qualche sniffing UA nel codice JS, perché la mia proprietà 'cssRule' è osservabile la regola css usata nel mio mark up cambia istantaneamente, e ha effetto.