É verdade que eu não deveria fazer "longa duração" coisas em um acessor propriedade?

votos
8

E em caso afirmativo, por quê? e que constitui a longa duração?

Fazendo mágica em um acessor propriedade parece que a minha prerrogativa como um designer de classe. Eu sempre achei que é por isso que os designers do C # colocar essas coisas lá - então eu poderia fazer o que eu quero.

É claro que é uma boa prática para minimizar surpresas para os usuários de uma classe, e assim incorporar realmente longos coisas funcionando - por exemplo, uma análise de 10 minutos de Monte Carlo - em um método faz sentido.

Mas suponha que um acessor prop requer uma leitura db. Eu já tenho a conexão db aberto. Seria db código de acesso ser aceitável, dentro das expectativas normais, em um acessor propriedade?

Publicado 19/05/2009 em 16:37
fonte usuário
Em outras línguas...                            


8 respostas

votos
22

Como você mencionou, é uma surpresa para o usuário da classe. As pessoas estão acostumadas a ser capaz de fazer coisas como esta com propriedades (exemplo inventado segue :)

foreach (var item in bunchOfItems)
    foreach (var slot in someCollection)
        slot.Value = item.Value;

Isso parece muito natural, mas se item.Valuerealmente é bater o banco de dados cada vez que você acessá-lo, seria um desastre menor, e deve ser escrito de forma equivalente a isso:

foreach (var item in bunchOfItems)
{
   var temp = item.Value;
   foreach (var slot in someCollection)
      slot.Value = temp;
}

Por favor, ajudar a orientar as pessoas que utilizam seu código longe de perigos ocultos como este, e colocar as coisas lentas em métodos que as pessoas saibam que eles são lentos.

Há algumas exceções, é claro. Carregamento lento é bom, desde que a carga preguiçoso não vai levar algum insanamente longo período de tempo, e às vezes fazer as coisas propriedades é realmente útil para razões da reflexão e de ligação relacionados com dados, então talvez você vai querer dobrar esta regra. Mas não há muito sentido em violar a convenção e violar as expectativas das pessoas sem alguma razão específica para fazê-lo.

Respondeu 19/05/2009 em 16:42
fonte usuário

votos
12

Além das boas respostas já publicadas, vou acrescentar que o depurador exibe automaticamente os valores das propriedades quando você inspecionar uma instância de uma classe. Você realmente quer ser a depuração do código e tem banco de dados recupera acontecendo no depurador cada vez que você inspecione sua classe? Seja legal com os futuros mantenedores de seu código e não fazer isso.

Além disso, esta questão é amplamente discutidos nas Diretrizes de Design Framework ; considere pegar uma cópia.

Respondeu 19/05/2009 em 19:45
fonte usuário

votos
3

É apenas uma "boa prática" para não fazer os assessores da propriedade levando muito tempo para executar. Isso é porque as propriedades parece com campos para o chamador chamador e, portanto, (um usuário de sua API que é) geralmente assume que não é nada mais do que apenas um "smth voltar";

Se você realmente precisar de alguma "ação" nos bastidores, considerar a criação de um método para que ...

Respondeu 19/05/2009 em 16:41
fonte usuário

votos
3

Você pode fazer o que quiser, mas você deve manter os consumidores de sua API em mente. Acessores e mutantes (getters e formadores) devem ser muito leve. Com essa expectativa, os desenvolvedores consumindo sua API pode fazer chamadas freqüentes e tagarelas para essas propriedades. Se você está consumindo recursos externos na sua implementação, pode haver um gargalo inesperado.

Pelo amor de consistência, é bom ficar com convenção para APIs públicas. Se suas implementações será exclusivamente privado, então não há provavelmente nenhum dano (que não seja uma abordagem inconsistente para resolver os problemas privadamente contra publicamente).

Respondeu 19/05/2009 em 16:41
fonte usuário

votos
3

Uma leitura db em um acessor propriedade seria ótimo - isso é realmente o todo ponto de carregamento lento. Eu acho que a coisa mais importante seria a de documentar-lo bem para que os usuários da classe a entender que poderia haver um impacto no desempenho ao acessar essa propriedade.

Respondeu 19/05/2009 em 16:40
fonte usuário

votos
1

Um acesso de banco de dados em uma propriedade de apanhador é bom, mas tentar limitar a quantidade de vezes que o banco de dados é atingido através de cache o valor.

Há muitas vezes que as pessoas usam propriedades em voltas sem pensar sobre o desempenho, então você tem que antecipar esse uso. Programadores nem sempre armazenar o valor de uma propriedade quando eles estão indo para usá-lo muitas vezes.

Cache o valor retornado do banco de dados em uma variável privada, se é viável para este pedaço de dados. Desta forma, os acessos são geralmente muito rápido.

Respondeu 19/05/2009 em 16:50
fonte usuário

votos
1

Não vejo qual é o problema com isso, contanto que você fornecer a documentação XML para que o Intellisense notifica consumidor do objeto do que eles estão se metendo.

Penso que esta é uma daquelas situações em que não existe uma resposta certa. Meu lema é "Dizer sempre é quase sempre errado." Você deve fazer o que faz mais sentido em qualquer situação sem levar em conta generalizações.

Respondeu 19/05/2009 em 16:40
fonte usuário

votos
0

Isso não está diretamente relacionada à sua pergunta, mas você já pensou indo com uma carga de uma vez abordagem em combinação com um parâmetro de atualização?

class Example
    {
        private bool userNameLoaded = false;
        private string userName = "";
        public string UserName(bool refresh)
        {
            userNameLoaded = !refresh;   
            return UserName();
        }
        public string UserName()
        {
            if (!userNameLoaded)
            {
                /*
                userName=SomeDBMethod();
                */
                userNameLoaded = true;                    
            }
            return userName;         
        }
    }
Respondeu 26/05/2009 em 22:42
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more