Dans mon expérience limitée, les choses sont comme vous le décrivez, c'est une situation délicate et de la cop-out "ça dépend" réponse s'applique.
Un bon exemple en est la boutique en ligne que je travaille pour. Il a un Brand de l'objet, et sur la page principale du site Web, toutes les marques que le magasin vend sont répertoriés sur le côté gauche. Pour afficher ce menu, de marques, tous les besoins du site est l'entier BrandId et la chaîne BrandName. Mais l' Brand objet contient toute une cargaison d'autres propriétés, notamment une en Description de la propriété qui peut contenir sensiblement grande quantité de texte à propos de l' Brand. N'y a pas deux manières à ce sujet, le chargement de tous les de que des informations supplémentaires à propos de la marque juste pour cracher son nom dans une liste non ordonnée (1), de façon mesurable, et de ralentir considérablement, généralement en raison du grand champs de texte et (2) assez inefficace quand il s'agit de l'utilisation de la mémoire, la construction de gros des chaînes et même pas les regarder avant de les jeter.
Une option offerte par de nombreux Orm est différé charge d'une propriété. Nous avons donc pu avoir un Brand objet retourné à nous, mais qui prennent du temps et de la mémoire de gaspiller Description champ n'est pas jusqu'à ce que nous essayons d'appeler sa get accesseur. À ce stade, l'objet proxy intercepte l'appel et sucer en bas de la description à partir de la base de données juste à temps. C'est parfois assez bon, mais a m'a brûlée suffisamment de fois que personnellement, je ne le recommande pas:
- Il est facile d'oublier que la propriété est en chargement paresseux, présentant une sélection de N+1 problème en écrivant simplement une boucle foreach. Qui sait ce qui se passe quand LINQ s'en mêle.
- Que faire si le juste-à-temps à la base de données échoue parce que le transport a obtenu coupe le sifflet ou le réseau est allé? Je peux presque garantir que le code qui est en train de faire quelque chose d'aussi anodin qu'
string desc = brand.Description ne s'attendait pas que le simple appel pour lancer une DataAccessException. Maintenant, vous avez juste s'est écrasé dans un de méchant et de manière inattendue. (Oui, j'ai regardé mon application descendre dur à cause de cela. Appris à la dure!)
Donc ce que j'ai fini par faire, c'est que dans les scénarios qui nécessitent des performances ou sont sujettes à la base de données des blocages, j'ai créer une autre interface que le site Web ou tout autre programme peut appeler pour obtenir l'accès à des blocs de données qui ont eu leur requête plans soigneusement examiné. L'architecture finit par trouver le type de cela (pardonnez l'ASCII art):
Site Web: Classes De Contrôleur
|
|---------------------------------+
| |
Serveur d'application: IDocumentService IOrderService, IInventoryService, etc
(Tableaux, bases de données) (Régulier OO objets, comme la Marque)
| |
| |
| |
La Couche de données: (Raw ADO.NET le retour des tableaux, ("la crème entière" ORM comme NHibernate)
Ensembles de données, des classes simples)
Je pensais que c'était de la triche, une subversion de l'OO modèle d'objet. Mais dans un sens pratique, aussi longtemps que vous faites ce raccourci pour afficher les données, je pense que c'est tout droit. Les mises à jour/inserts et qu'avez-vous encore passer par le pleinement hydratée, ORM-rempli modèle de domaine, et c'est quelque chose qui arrive beaucoup moins souvent (dans mon cas) que l'affichage de certains sous-ensembles de données. Orm comme NHibernate vous permettra de faire des projections, mais à ce stade, je ne vois pas l'intérêt de l'ORM. Ce sera probablement une procédure stockée de toute façon, l'écriture de l'ADO.NET prend deux secondes.
C'est juste mes deux cents. J'ai hâte de lire les autres réponses.
