È una cattiva pratica costruire un grande componente web come Helper Html?

1

Quindi, dalla mia comprensione, gli helper Html dovrebbero essere per singoli elementi o piccoli frammenti di html. Tuttavia, non sono proprio sicuro del motivo per cui penso questo, o di come mi sono attenuto alla pratica. Non sono riuscito a trovare nulla da Microsoft che riguardi questo argomento.

Il motivo per cui lo chiedo è che recentemente mi è stato chiesto di creare un componente web abbastanza grande come un singolo Html Helper, che costruisce il suo html usando nient'altro che TagBuilders.

Questo componente avrà molti elementi diversi; div divisioni, input, selezioni ed elenchi multipli. Come riferimento, si tratta di un controllo di immissione degli indirizzi, ma supporta la scelta tra l'inserimento manuale o la ricerca tramite codice postale e la selezione, e consente di tornare indietro e modificare l'indirizzo. In totale ha 5 diversi "punti di vista".

Mi sento come se costruissi interamente questo tag con TagBuilder, il risultato sarà un markup illeggibile. Sono solo un piccolo passo avanti in questo compito ed è già difficile capire a colpo d'occhio quale markup produce, ma mi chiedo se è perché costruire una grande quantità di html con TagBuilder è una cattiva pratica, o se sto facendo qualcosa di sbagliato .

Quindi è una cattiva pratica fare questo, e se sì, perché?

    
posta Jonah 22.04.2018 - 00:46
fonte

3 risposte

2

Sì. Direi che lo stile di controllo dell'Help HTML statico è un po 'insolito e considerato una cattiva pratica a meno che tu non abbia una buona ragione per usarlo.

La ragione è che devi creare il codice HTML nel codice piuttosto che il template. il che rende problematico cambiare e mantenere.

L'alternativa sarebbe una serie di modellini di vista e viste parziali. Il lato negativo è che sono più difficili da distribuire come una singola cosa.

Un'altra scusa per usare l'helper è usare (o abusare) la sintassi usando (Html.BeginForm) in modo da ottenere automaticamente i tag di chiusura

    
risposta data 22.04.2018 - 16:52
fonte
2

Se stai mettendo in dubbio il tuo codice, probabilmente significa che lo farà anche qualcun altro. Tieni sempre a mente i principi SOLID, in particolare la singola responsabilità. Ho costruito grandi pagine di markup in passato, quello che credo funzioni meglio è avere componenti più piccoli che compongono la pagina. Con Razor puoi sfruttare i partial.

    
risposta data 22.04.2018 - 05:28
fonte
0

Per mantenere le preoccupazioni separate e pulite, è consigliabile non caricare il server con molta logica di costruzione html. Ho anche avuto qualche dubbio e ho trovato un buon articolo che spiega perché uno vorrebbe evitare così. Di seguito è riportato il ragionamento diretto da questo:

There are five reasons from my perspective, good enough to prefer a mature and well designed JavaScript framework versus ASP.NET MVC. This is not performance related at all. I will not come with reasons like 'ASP.NET MVC is a server side development framework so it imposes and extra load on web server due to rendering (Razor Engine or ASP Engine) while Angular has an impact strictly on client machine'. As you noticed, my favorite JavaScript framework is Angular and that is not because it was developed at Google, it is because I find it to be a very elegant and comprehensive framework, this is a subjective opinion any way. I will start to present my five reasons from the most superficial to the most realistic.

First reason of all, mixed code...I really dislike it, I really do. Even after so many years of working with ASP.NET (WebForms and MVC) I still can't accommodate with it. The look and feel of server side code embedded into pages (chtml pages in my case) is a true pain for my eyes. I find it difficult to follow the code logic and navigate through it. Not to mention the fact that some people can be really inventive when it comes to what server side code generates in the page.

The second reason is, OK this is strictly my opinion so I might be wrong about it, client code is for clients and server code is for servers, simple as that. What has to deal with client side, is mainly related to how data is retrieved, presented and how the end user interacts with it should be a client side code concern only (let the browser do its job). Same thing applies to server side, let the server side code handle all business logic, data persistence and all the another nuisance aspects, don't bother the server with concerns about how the information has to be presented and how the end user should interact with it. I always choose SOA approach for my applications which can be either SOAP either REST.

The third reason is, there is no way a designer (not sure if this is the most appropriate term for an HTML/CSS expert) will work easily on pages which have server side code embedded. The "why?" is quite obvious I assume. Unless you are lucky enough to have an experienced developer on both fields (HTML/CSS and ASP.NET MVC). The server side code is way too intrusive from my point of view, compared with how Angular works. The forth reason is, most developers do not pay same attention to both sides. How many times have you seen JavaScript code sprinkled in pages? How many times have you seen JavaScript functions flying around? How many times have you seen JavaScript code blocks without being encapsulated in a namespace? You know why? Because the main idea behind having server side code to generate UI is to cover the lack of strong skills related to client side development (JavaScript, etc).

The fifth reason is, you can't test it. Yes, you can't test the final result unless the server code works as it should. Imagine that you want to check if your page always displays data in a strictly defined order. Or if amounts or dates for example are formatted correctly based on client culture. What will happen if there is a bug on server side code which doesn't allows you to build the project, or something goes wrong on data access layer? Are you going to be able to test your page? I think not. Same thing doesn't apply if you have the client and server as totally separated tiers (as they should normally be, after all we are talking about client code and server code). You could easily mock the data needed in tests with JSON without carrying if the server is fine or not. You could easily do this sort of tests with Karma Test Runner for example.

    
risposta data 22.04.2018 - 16:51
fonte

Leggi altre domande sui tag