Come organizzi un'applicazione ASP.NET MVC 3 con potenzialmente centinaia di visualizzazioni ma con solo pochi punti di accesso?

3

Ipotesi:

  • Applicazione ASP.NET MVC 3 minimalista per l'invio di email in cui la vista rappresenta il contenuto di un'email.
  • Oltre 500 tipi di email. Non mi piacerebbe avere più di 500 azioni nel mio controller corrispondenti a ciascun tipo di email.
  • I tipi di email sono memorizzati in un enum chiamato MailType, quindi potremmo avere:
    • MailType.ThankYouForYourPurchase, MailType.OrderShipped, ecc.
  • Il nome della vista è uguale al nome mailType:
    • MailType.OrderShipped avrebbe una vista corrispondente: OrderShipped.cshtml
  • Alcune viste utilizzerebbero direttamente un'entità mentre altre utilizzerebbero un ViewModel.

Quindi, dato che ho più di 500 tipi di email, qual è il modo migliore / pattern per organizzare la mia applicazione?

Ecco cosa stavo pensando,

Controller:

    public class MailController : Controller
    {
        public ActionResult ViewEmail(MailType mailType, int customerId)
        {
            string viewName = mailType.ToString();

            var model = _mailRepository.GetViewModel(mailType, customerId);

            return View(viewName, model);
        }

        public ActionResult SendEmail(MailType mailType, int customerId)
        {
            ...
        }
    }

Classe MailRepository:

    public class MailRepository
    {
        private readonly CustomerRepository _customerRepository;
        private readonly OrderRepository _orderRepository;

        //pretend we're using dependency injection
        public MailRepository()
        {
            _customerRepository = new CustomerRepository();
            _orderRepository = new OrderRepository();
        }

        public object GetViewModel(MailType mailType, int customerId)
        {
            switch (mailType)
            {
                case MailType.OrderShipped:
                    return OrderShipped(customerId);
                case MailType.ThankYouForYourPurchase:
                    return ThankYouForYourPurchase(customerId);
            }

            return _customerRepository.Get(customerId);
        }

        public Order OrderShipped(int customerId)
        {
            //Possibly 30 lines to build up the model...
            return _orderRepository.GetByCustomerId(customerId);
        }

        public Customer ThankYouForYourPurchase(int customerId)
        {
            return _customerRepository.Get(customerId);
        }
    }

Ma in questo modo la mia classe MailRepository diventerà estremamente grande a meno che non lo renda in qualche modo ...

    
posta Randy Burden 25.10.2011 - 02:03
fonte

2 risposte

3

Per evitare che una classe diventi troppo grande devi mappare i tipi di posta alle classi anziché i nomi dei metodi: scegli una convenzione di denominazione come MailControllers.OrderShippedController e carica la classe con il riflesso.

Vorrei anche notare che il tuo MailRepository sembra comportarsi più come un controller - non è un grosso problema, ma qualcosa che potrebbe confondere in seguito.

    
risposta data 25.10.2011 - 02:23
fonte
1

@Tom La risposta di Clarkson è buona. Inoltre, se non lo stai già facendo, potresti utilizzare un contenitore IOC come Spring.NET per esempio per dichiarare un "MailTypeRetriever" fagiolo. L'unico parametro nel costruttore di questo bean deve essere una mappa (dizionario) con la chiave come tipo di posta e il valore il nome del metodo da chiamare.

In questo modo la configurazione del tuo tipo di posta non è nel tuo codice e il codice per chiamare il metodo giusto sarà breve. Ovviamente, non hai bisogno di Spring per esternalizzare la tua configurazione del tipo di posta, questo è solo un modo per farlo.

    
risposta data 25.10.2011 - 07:48
fonte

Leggi altre domande sui tag