Est-ce que ça va d'utiliser c # propriété comme ça

Les propriétés doivent vraiment être aussi légères que possible.

Lorsque d'autres développeurs utilisent des propriétés, ils s'attendent à ce qu'ils soient des parties intrinsèques de l'objet (c'est-à-dire déjà chargées et en mémoire).

Le vrai problème ici est celui de la symétrie - la propriété get and Set devrait se refléter mutuellement, et ils ne le font pas. C'est contre ce que la plupart des développeurs s'attendent normalement.

Avoir la charge de la propriété à partir de la base de données n'est pas recommandée - Normalement, on remplacerait la classe via une méthode spécifique.

À mon avis, c'est un design terrible. Utiliser une propriété getter pour faire des choses "magiques" rend le système gênant de gérer. Si je rejoindrais votre équipe, comment devrais-je savoir cette magie derrière ces propriétés?

Créer une méthode distincte appelée comme elle se comporte.

"correct" est souvent dans l'œil du spectateur. Cela dépend aussi de la distance ou de la brillante que vous voulez que votre conception soit. Je n'irais jamais pour la conception que vous décrivez, cela deviendrai un cauchemar de maintenance pour avoir les actions crudes sur les Pocos.

Votre problème principal est l'absence de séparations de préoccupations em> strong>. I.E., l'objet de données est également responsable de la conservation et de la récupération (actions qui doivent être définies une seule fois dans l'ensemble du système). En conséquence, vous vous retrouvez avec un code dupliqué, ballonné et immobilable qui peut rapidement devenir réel lent (essayez une requête LINQ avec une jointure sur le gettor). P>

Un scénario courant avec des bases de données consiste à utiliser de petites classes d'entité qui ne contiennent que les propriétés, rien de plus. Une couche DAO s'occupe de la récupération et de la remplissage de ces POCOS avec des données de la base de données et défini uniquement les actions crudes uniquement (à travers des génériques). Je suggérerais NHibernate pour la cartographie ORM. Le principe de base expliqué ici fonctionne également avec d'autres mappeurs Orm et est aussi expliqué ici . p>

Les raisons, esp. NR 1, devrait être un candidat principal pour le refactoriser dans quelque chose de plus maintenu. Le code dupliqué et la logique, lorsqu'ils sont rencontrés, devraient être reconsidéré fortement. Si le gettor ci-dessus obtient réellement les données de la base de données (j'espère que j'ai mal comprendre cela), éliminez-le aussi rapidement que possible. P>

Exemple trop simplifié de séparations de préoccupations: P>

class Data 
{
    public string Prop1 {get; set;}
    public string Prop2 {get; set;}
}

class Dao<T>
{
    SaveEntity<T>(T data)
    {
        // use reflection for saving your properies (this is what any ORM does for you)
    }
    IList<T> GetAll<T>()
    {
        // use reflection to retrieve all data of this type (again, ORM does this for you)
    }
}

// usage:
Dao<Data> myDao = new Dao<Data>();
List<Data> allData = myDao.GetAll();
// modify, query etc using Dao, lazy evaluation and caching is done by the ORM for performance
// but more importantly, this design keeps your code clean, readable and maintainable.

Je ne pense pas qu'un autre développeur qui fonctionnera avec le même code sera heureux de voir: xxx

personnellement, je ne ferais jamais cela.

aussi Ce n'est pas la meilleure idée d'utiliser la propriété pour charger des données de DB. J'aurais méthode qui chargera des données de DB à une variable locale, puis vous pouvez obtenir ces données à l'aide de la propriété. Aussi get / Set logiquement doit fonctionner avec les mêmes données. Il est étrange d'utiliser obtenir pour obtenir des données à partir de dB mais d'utiliser définir pour fonctionner avec une variable locale.