Pergunta

Este é principalmente um pedido de comentários se houver um motivo pelo qual eu deveria não Desça essa estrada.

Eu tenho um aplicativo gerado por codesmith de vários níveis. No nível da interface do usuário, é necessário haver alguns campos necessários e os campos necessários variarão dependendo dos valores de campo na entidade ligada. O que estou pensando em fazer é adicionar um atributo "PropertyRewired" para cada propriedade nas entidades que eu posso definir verdadeiro ou falso quando carrego a entidade em seu gerente. Em seguida, usarei a reflexão para consultar a propriedade e dar feedback visual ao usuário no nível da interface do usuário, e posso validar que todas as propriedades necessárias têm um valor válido no gerente antes de economizar. Eu trabalhei isso como uma prova de conceito com uma propriedade em uma entidade, mas antes de tentar estendê -la ao resto do aplicativo, eu gostaria de perguntar se há alguém com mais experiência para me dizer para ir Para isso, ou por que não vou gostar quando escalar. Se essa é uma má ideia, ou se você pode sugerir uma abordagem melhor, ofereça sua opinião.

Foi útil?

Solução

É uma maneira bastante razoável de fazê -lo (já fiz algo muito parecido antes) - mas há sempre desvantagens:

  • Qualquer código que precise da entidade precisará da referência extra (assumindo que o atributo e a entidade estejam em diferentes montagens)
  • Os valores (a menos que você seja inteligente sobre isso) devem ser determinados em tempo de compilação
  • Você não pode usá -lo em entidades fora do seu controle

Na maioria dos casos, o exposto acima não é um problema. Se eles são Um problema, você pode querer apoiar um modelo de metadados externos - mas a não ser que Você precisa disso, isso seria um exagero. Não faça isso a menos que você deva (significando: vá em frente e use atributos; eles são usualmente multar).

Outras dicas

Não há motivo inerente para evitar atributos personalizados. É um recurso CLR suportado que é a espinha dorsal para muitos produtos disponíveis (contratos de código, FXCOP, etc ...).

Esta não é uma abordagem irracional e mais saudável do que assar essas coisas em uma camada da interface do usuário. Há alguns pontos que valem a pena considerar antes de mergulhar:

  • Você está acoplando firmemente a lógica de negócios com a própria entidade comercial. Existem circunstâncias em que um campo é necessário ou valores válidos podem mudar? Você pode estar se limitando ou enfrente um mecanismo de validação inconsistente
  • A atribuição dinâmica é possível, mas mais complicada - ou seja, quando você define um campo para ser necessário, isso será o que será, a menos que você substitua
  • Os atributos personalizados podem ser bastante inflexíveis se mais adiante, você deseja fazer algo mais complicado - a saber, se você precisar passar o estado em um esquema de validação acionado por atributos. Atributos como atribuição declarativa. Apenas ter uma propriedade necessária verdadeira/falsa não deve ser um problema aqui

Apenas sendo um advogado do Devils, em geral, para uma aplicação bastante simples, onde você só se importa com os campos necessários, essa é uma maneira bastante arrumada de fazer isso

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top