[ASP.NET/MySQL] MySQL e MVC4

[Typo]

Ciao a tutti.

Cerco in rete da un po ma non riesco a trovare veramente nulla, o meglio ci sono parecchi articoli ma non spiegano quello che vorrei capire. Premetto che so cosa significa MVC dato che ho programmato per svariato tempo in PHP sia con CodeIgniter che con Laravel. Ho deciso da poco di passare a ASP.NET dato che ho una conoscenza migliore di VB.NET / C# rispetto al PHP.

Non mi è mai piaciuto SQL SERVER ( tra le altre cose costa anche parecchio ) quindi volevo far funzionare ASP.NET con MYSQL e in parte ci sono riuscito, solo che credo nella maniera sbagliata.

Ho letto anche che si può usare l'entity framework e che si può utilizzare il concetto di CodeFirst eliminando praticamente la creazione manuale dei modelli e delle viste ma non mi interessa. Vorrei se possibile fare esattamente come faccio nelle Desktop Application , ovvero accantonare tutti i Wizard Microsoft che a mio parere creano solo confusione soprattutto in progetti di certe dimensioni ( forse sbaglio )

Per fare una prova ho creato un semplice Controller e un Model

Nel Model ho aggiunto i 3 campi propietà

    Public Property IDCliente As Integer
    Public Property Nome As String
    Public Property Cognome As String

e fin qui tutto OK ! Poi ho creato un Controller nel quale ho aggiunto semplicemente una funzione che ritorna la Vista, e una funzione per l'inserimento del cliente che ho strutturato in questo modo

    Public Function NuovoCliente(ByVal Nome As String, ByVal Cognome As String)
        Dim cliente As New Cliente
        cliente.Nome = Nome
        cliente.Cognome = Cognome
        cliente.Inserisci()
        Return True
    End Function

quindi nel controller non faccio altro che prendere i parametri inseriti dall'utente creare una nuova istanza del MODEL e quindi avviare la funzione di inserimento che è simile a questa

    Public Function Inserisci()
        Dim Connessione = New MySqlConnection("Database=learning;Data Source=localhost;Port=3307;User Id=root;Password=59929603;")
        Connessione.Open()
        Dim SQL As String
        Dim CMD As New MySqlCommand

        SQL = "INSERT INTO clienti(Nome,Cognome)VALUES('" & Me.Nome & "','" & Me.Cognome & "')"
        CMD.Connection = Connessione
        CMD.CommandText = SQL
        CMD.ExecuteNonQuery()
        Connessione.Close()
    End Function

secondo me però sbaglio tutto perchè fondamentalmente questa è la logica che si usa con PHP non so quanto possa funzionare anche per asp.net.
Il codice ovviamente funziona, l'inserimento viene effettuato correttamente.

[URANIO]

Cosa non ti sconfinfera?

[Typo]

Tutto, cioè la logica che ho utilizzato veniva applicata anche su CodeIgniter anche se PHP non è esattamente OOP.

Quello che vi chiedo è questo : è corretto tenere questa logica

Controller : Contiene i metodi che creano un istanza del model, riempiono le proprietà con i parametri passati dal cliente ed invocano il metodo necessario all'interno del model

Model : Riceve i dati dal controller, crea un istanza della classe per la gestione del Database e provvede all'inserimento

View: riceve l'oggetto appena inserito tramite viewbag o simili per permettere di visualizzare il risultato all'utente.

Lo chiedo perchè qualsiasi guida sia riuscito a trovare sin ora, compresa quella prodotta direttamente da Microsoft si avvale dell'EF5 e non spiegano esattamente questo concetto ma lasciano tutto all'IDE, si limitano alla ceazione dlele tabelle

[URANIO]

Effettivamente tutorial MVC che non usino EF sono impossibili da trovare (se ci pensi anche le varie guide PHP usano sempre ORM).
Comunque EF si occupa solo del model, e permette di gestire il database senza usare query.

Comunque come logica sembra corretta, MVC è uguale per tutti, l'importante è capire chi deve fare cosa.

Ovviamente rivedrei un po il codice del Model.Inserisci(), la stringa di connessione prendila dal webconfig e magari cerca di renderlo dinamico in base alle proprietà della model.

[Typo]

certo questo è ovvio, quella era solo una " sperimentazione " per ambientarmi ho un intera classe che si occupa della gestione di MySQL, praticamente ho un mio piccolo framework che mi permette di essere molto più produttivo al momento, rispetto ad EF, data la mia scarsa conoscenza del suddetto.
Ciò non toglie che prima o poi dovrò approfondire, volevo solo essere sicuro ( dato che ,come ho detto prima, nessuna accenna minimamente alla progettazione senza EF ) che la classica logica MVC andasse bene.

Ti ringrazio per il tuo aiuto

[rsdpzed]

ritengo fuorvianti i tutorial con i model costruiti con entity framework. Dire che la M di MVC sia il modello di business è un errore. Se parliamo di bookstore ok, ma la realtà non è mai fatta da un database autori->libri...
Per rispondere al tuo secondo post, non teoricamente ma restando nel modo con cui asp.net mvc implementa il pattern mvc:

Il controller contiene metodi pubblici (chiamati action) che possono essere richiamati dall'utente via http. Un applicazione quindi non è piu fatta da pagine fisicamente presenti sul server ma da METODI. Da parte dell'utente esistono diversi modi per interagire con l'applicazione: puo fare una richiesta (http-get) o puo inviare dei dati (http-post).
Il controller riceve la richiesta, la elabora, prepara i dati che rappresentano la risposta ma non si occupa di preparare la risposta. Generalmente la risposta è una view in html, la cui complessità viene gestita da un engine. Il controller quindi deve passare all'engine per prima cosa un template html e un model che "riempirà" quel template. Il compito dello sviluppatore è quello di:
.Scrivere il template che nel caso specifico è una pagina html con sintassi razor.
.Scrivere la classe Model cucita addosso al template e quindi alla view e che nulla ha a che fare con il proprio modello di business.
.Richiamare i metodi di business dal controller e riversare i risultati nel Model ma solo quelli che interessano alla view.
.Arricchire, eventualmente il model con informazioni specifiche della view.
.Richiamare la view passandogli come argomento il model.

Quando dico "richiamare metodi di business" intendo fai le query al database, oppure richiama una classe che fa le query al database e ti ritorna i risultati in classi che rappresentano il tuo modello di business. La cosa fondamentale è non mischiare questo con il Model di MVC.

per farla breve io nel controller ho pezzi di codice cosi:

//Cliente è una classe del mio modello di business, ClientiManager è una classe di business che si occupa delle operazioni di CRUD con il database, non centrano con MVC e generalmente le tengo in una dll separata.
Cliente cliente = bl.ClientiManager.ClienteByID(3);

//Questo è il mio model. Gia dal nome si capisce che l'ho scritta pensando non alla classe Cliente ma alla view! è ovvio che conterrà le informazioni tipiche di un cliente ma non è detto che debbano essere solo quelle...
DettagliClienteVM vm = new DettagliClienteVM();
vm.Nome = cliente.Nome;
vm.Cognome = cognome;
//...infatti:
vm.IP = Request.UserHostAddress

//richiamo l'engine selezionando a) il template e passandogli b) il model.
return View("DettagliCliente",vm);

@model Applicazione.Model.DettagliClienteVM

<h3>@Model.Cognome, @Model.Nome<h3>

<span>il tuo ip è: @Model.IP</span>

il model è una classe passiva, non ha una logica (tranne qualche metodo get forse) e soprattutto non puo avere metodi di conversione da o verso le corrispondenti classi di business perchè altrimenti si commetterebbe l'errore di legarle implicitamente ad esse (ritornando punto e dacapo). Lo dico perchè anch'io ho commesso nel mio primo lavoro reale con asp.net mvc l'errore di inserire nelle classi Model metodi tipo questo:

vm.FromEntity(cliente); //accoppiamento di due classi che non devono essere accoppiate!

errore scoperto troppo tardi e che a suo tempo mi è costato ore di refactoring...

[Typo]

Ciao,

prima di tutto grazie per la tua risposta, molto dettagliata.

E' infatti quello che pensavo anche io, questo tra l'altro ha diversi vantaggi a livello di riusabilità del codice, seguendo il tuo ragionamento, se ho capito bene, io dovrei prendere le mie classi Business ( utilizzate ovviamente anche nelle desktop application ) e farne uso anche nella web application, senza però mischiarle in nessun modo con il pattern MVC.

Quindi teoricamente
il Model contiene sia l'oggetto Cliente ( classe creata precedentemente in base alle proprie necessità indipendenti dall'utilizzo Desktop/Web) sia tutte le altre propietà indipendenti dalla classe Cliente pura necessarie alla visualizzazione della View, quindi come da tuo esempio l'indirizzo IP.

Grazie mille

[rsdpzed]

Originariamente inviato da Typo
il Model contiene sia l'oggetto Cliente

una precisazione (non una regola ma un consiglio dettato piu dall'esperienza pratica). Questi sono tre modi di scrivere un model, a prima vista tutti legittimi ma i primi due per me non rappresentano una scelta giusta (cosa che viene fuori su progetti piu consistenti di un esempio):

public class DettagliClienteVM
{
  public Cliente Cliente {get;set;}
  public string IP {get;set;}
}

public class DettagliClienteVM
{
  public DettagliClienteVM(Cliente cliente)
  {
     this.Nome = cliente.Nome;
     this.Cognome = cliente.Cognome;
     this.Citta = (cliente.Citta != null) ? cliente.Citta.NomeCitta : string.Empty;
  }

  public string Nome {get;set;}
  public string Cognome {get;set;}
  public string Citta{get;set;}
  public string IP {get;set;}
}

public class DettagliClienteVM
{
  public string Nome {get;set;}
  public string Cognome {get;set;}
  public string Citta{get;set;}
  public string IP {get;set;}
}

Il primo esempio è il piu semplice da implementare ma anche il piu rigido. Devo portarmi dietro fino alla view il mio modello di business e consocere, fin dentro la view come interagiscono le classi del mio modello di business. sono costretto, con razor, a scrivere cose come: <span>Citta: @Model.Cliente.Citta.Nomecitta</span>. Intellisense di vs2010 arriva fin dentro razor ma non gestisce le modifiche se cambi un nome nelle classi di business. Non ho una chance di verificare l'integrità dei dati (se città è null? faccio l'if nella view con razor?)

Il secondo esempio gia va meglio. Ho un Model ritagliato sulla view, ma lascio al model una respinsabilità in piu cioè quella di popolare le sue informazioni dagli oggetti di business. Per view complesse un model diventerebbe anch'esso complesso. E poi perchè l'IP lo deve passare il controller mentre le informazioni dal modello di business se le deve caricare il model? A questo punto perche non demandare questo compito direttamente al controller?

Il terzo model è piu pulito, meno complesso (non fa nulla) e si aspetta di essere "riempito" dal controller. Che si occupi il controller di gestire quali informazioni inserire, da dove prenderle (cache? classi di business?, direttamente da orm o ADO.NET?). In questo modo tutto cio che concerne la logica di business dell'applicazione rimane circoscritto nei controller.