O código embutido em suas páginas aspx é uma boa prática?

Question

Se eu usar o código a seguir, perco a capacidade de clicar com o botão direito nas variáveis ​​no código por trás e refatorá-las (renomeá-las neste caso)

<a href='<%# "/Admin/Content/EditResource.aspx?ResourceId=" + Eval("Id").ToString() %>'>Edit</a>

Vejo essa prática em todos os lugares, mas parece estranho para mim, pois não consigo mais obter erros de tempo de compilação se alterar o nome da propriedade.Minha abordagem preferida é fazer algo assim

<a runat="server" id="MyLink">Edit</a>

e então no código por trás

MyLink.Href= "/Admin/Content/EditResource.aspx?ResourceId=" + myObject.Id;

Estou realmente interessado em saber se as pessoas acham que a abordagem acima é melhor, pois é isso que sempre vejo em sites e blogs de codificação populares (por exemplo,Scott Guthrie) e é um código menor, mas costumo usar ASP.NET porque ele é compilado e prefiro saber se algo está quebrado em tempo de compilação e não em tempo de execução.

Answer 1

Eu não chamaria isso de má prática (alguns discordariam, mas por que eles nos deram essa opção em primeiro lugar?), mas eu diria que você melhorará a legibilidade e a manutenção geral se não se submeter a essa prática.Você já transmitiu um bom ponto: a limitação dos recursos do IDE (ou seja, inspeção de tempo de design, aviso de tempo de compilação, etc.).

Eu poderia continuar falando sobre quantos princípios ele viola (reutilização de código, separação de interesses, etc.), mas posso pensar em muitos aplicativos por aí que quebram quase todos os princípios, mas ainda funcionam depois de vários anos.Eu, pelo menos, prefiro tornar meu código o mais modular e sustentável possível.

Answer 2

É conhecido como código espaguete e muitos programadores o consideram questionável...por outro lado, se você e os outros desenvolvedores da sua empresa acharem que ele é legível e fácil de manter, quem sou eu para lhe dizer o que fazer.

Com certeza, use include para reduzir a redundância (DRY - não se repita)

Answer 3

Eu o uso apenas ocasionalmente e geralmente por algum motivo específico.Sempre serei um desenvolvedor mais feliz com meu código totalmente separado da marcação HTML.É uma preferência pessoal, mas eu diria que é uma prática melhor.

Answer 4

Você decide.Às vezes, o código "spagehetti" é mais fácil de manter do que construir/usar um sistema completo de templates para algo simples, mas quando você obtém páginas bastante complicadas, ou mais especificamente, quando você começa a incluir muita lógica na própria página, ele pode ficar sujo muito rapidamente.

Answer 5

Acho interessante que mais asp.net exija código nas páginas aspx.O listview no 3.5 e até o ASP.NET MVC.O MVC basicamente não possui código por trás, mas sim código nas páginas para renderizar informações.

Answer 6

Se você pensar nisso em termos de desenvolvimento de modelo, é aconselhável mantê-lo na visualização e não no código por trás.E se for necessário mudar de uma âncora para um item de lista com JS discreto para lidar com um clique?Sim, este não é o melhor exemplo, apenas isso e um exemplo.

Eu sempre tento pensar em termos de se eu tivesse um designer (HTML, CSS, qualquer coisa), o que ele faria e o que eu estaria fazendo no código por trás, e como não pisaríamos no pé um do outro.

Answer 7

É apenas uma prática ruim, se você não conseguir encapsular bem.

Como tudo mais, você pode criar códigos espaguete desagradáveis ​​e ilegíveis, exceto que agora você tem tags para se contentar, que por design não são as coisas mais legíveis do mundo.

Eu tento manter toneladas de if fora do modelo, mas o encapsulamento excessivo leva a ter que procurar em 13 lugares diferentes para ver por que div x não está disparando para o cliente, então é uma troca.

Answer 8

Não é, mas às vezes é um mal necessário.

Veja o seu caso, por exemplo, embora o código por trás pareça ter uma melhor separação de preocupações, mas o problema é que ele pode não separar as preocupações tão claramente quanto você deseja.Normalmente, quando fazemos o código por trás das coisas, não estamos construindo os aplicativos na estrutura MVC.O código por trás do código também não é fácil de manter e testar, pelo menos quando comparado ao MVC.

Se você estiver criando aplicativos ASP.NET MVC, acho que certamente está preso ao código embutido.Mas construir no padrão MVC é a melhor maneira de fazer em termos de manutenção e testabilidade.

Para resumir:código embutido não é uma boa prática, mas é um mal necessário.

Meus 2 centavos.

Answer 9

Normalmente eu uso assim.

<a href='<%# DataBinder.Eval(Container.DataItem,"Id",""/Admin/Content/EditResource.aspx?ResourceId={0}") %'>