Lequel préférez-vous pour la recherche/rapport DataTable ou DTO ou classe de domaine?

Question

Le projet dans lequel je travaille nécessite beaucoup de pages de recherche/filtrage. Par exemple, j'ai une page de recherche comlex pour obtenir des problèmes par données, catégorie, unité, ...

La classe de domaine de problème est complexe et contient beaucoup d'objets de valeur et d'objets enfants.

.Je me demande comment les gens font face à la recherche/filtrage/reporting pour l'interface utilisateur. Autant que je sache, j'ai 3 options mais aucune d'elles ne me rend plus heureux.

1.) Envoyer des paramètres au référentiel/DAO pour obtenir DataTable et Bind DataTable à l'interface utilisateur Controls.For Exemple à ASP.NET GridView

DataTable dataTable =issueReportRepository.FindBy(specs); 
..... 
grid.DataSource=dataTable; 
grid.DataBind(); 

Dans cette option, je peux simplement en passer la couche de domaine et requête base de données pour des spécifications données. Et je ne dois pas obtenir l'objet de domaine complexe entièrement construit. Pas besoin d'objets de valeur, objets enfants, .. Obtenir des données à afficher dans l'interface utilisateur dans DataTable directement à partir de la base de données et afficher dans l'interface utilisateur.

Mais si j'ai besoin d'afficher un champ calculé en UI comme la valeur de retour de la méthode, je dois le faire dans la base de données parce que je n'ai pas entièrement l'objet de domaine. Je dois dupliquer des problèmes de logique et de DataTable comme aucun intellisense etc ...

2.) Envoyer des paramètres au référentiel/DAO pour obtenir DTO et relier DTO aux contrôles d'IU.

IList<IssueDTO> issueDTOs =issueReportRepository.FindBy(specs); 
.... 
grid.DataSource=issueDTOs; 
grid.DataBind(); 

Cette option est la même que ci-dessus mais je dois créer des objets DTO anémiques pour chaque page de recherche. Aussi pour différentes pages de recherche de problème je dois montrer différentes parties du problème Objects.IssueSearchDTO, CompanyIssueTO, MyIssueDTO ....

3.) Envoyer des paramètres à la classe Real Repository pour obtenir des objets de domaine entièrement construits. J'ai aimé Domain Driven Design et Patterns. Dans cette option, je dois créer des lots d'objet enfant et valeur qui n'apparaîtront pas dans l'interface utilisateur. De plus, il faut que ob ob soit beaucoup pour obtenir l'objet de domaine complet et le coût de performance pour les enfants. objets et objets de valeur.

Je n'utilise aucun outil ORM Peut-être que je peux implémenter Lazy Loading à la main pour cette version mais cela semble un peu exagéré.

Lequel préférez-vous? Ou est-ce que je le fais mal? Y a-t-il des suggestions ou une meilleure façon de le faire?

Answer 1

J'ai quelques suggestions, mais bien sûr, la réponse globale est "ça dépend". Tout d'abord, vous devriez utiliser un outil ORM ou vous devriez avoir une très bonne raison de ne pas le faire.

En second lieu, la mise en œuvre Chargement Lazy à la main est relativement simple si dans le cas où vous ne comptez pas utiliser un outil ORM, vous pouvez simplement créer des propriétés sur vos objets qui disent quelque chose comme:

private Foo _foo; 
public Foo Foo 
{ 
    get { 
     if(_foo == null) 
     { 
      _foo = _repository.Get(id); 
     } 
     return _foo; 
     } 
} 

Troisièmement, la performance est quelque chose qui devrait être considéré au départ, mais ne devrait pas vous éloigner d'un design élégant. Je dirais que vous devriez utiliser (3) initialement et ne s'en écarter que si ses performances sont insuffisantes. Cela a pour résultat d'écrire le moins de code et d'avoir le moins de duplication possible dans votre conception.Si la performance en souffre, vous pouvez l'adresser facilement dans la couche d'interface utilisateur en utilisant Caching et/ou dans votre couche de domaine en utilisant Lazy Loading. Si ces deux éléments n'offrent pas de performances acceptables, vous pouvez revenir à une approche DTO dans laquelle vous ne retrouvez qu'une collection légère d'objets de valeur nécessaires.

Espérons que ça aide. Steve

Answer 2

Ceci est une grande question et je voulais fournir ma réponse aussi. Je pense que le meilleur techniquement meilleure réponse est d'aller avec l'option # 3. Il offre la possibilité de décrire et d'organiser au mieux les données ainsi que l'évolutivité pour les futures améliorations apportées aux requêtes de reporting/recherche. Bien que cela puisse être la meilleure option globale, il y a un coût énorme IMO par rapport aux autres (2) options qui sont le temps de conception supplémentaire pour toutes les classes et relations nécessaires pour prendre en charge les besoins de reporting (encore une fois). selon la prémisse qu'il n'y a pas d'outil ORM utilisé).

Je me bats avec cela dans beaucoup de mes applications et la réalité est que le # 2 est le meilleur compromis entre le temps et le design. Maintenant, si vous posez des questions sur vos objets busniess et tous leurs besoins, il est aucune question qu'un modèle entièrement conçu et correctement conçu est important et il n'y a pas de substitut. Cependant, quand il s'agit de rapporter et de chercher cela, c'est un animal différent. # 2 fournit des données fortement typées dans les classes anémiques et n'est pas aussi primitif que les valeurs codées en dur dans DataSets comme # 1, et réduit encore considérablement le temps nécessaire pour terminer la conception par rapport à # 3. Idéalement, j'adorerais étendre mon modèle d'objet pour couvrir tous les besoins de reporting, mais parfois l'effort requis pour le faire est si vaste, que la création d'un ensemble séparé de classes juste pour les besoins de reporting est une option plus facile mais viable. En fait, j'ai posé presque la même question il y a quelques années et on m'a dit que créer un autre ensemble de classes (essentiellement des DTO) pour les besoins de rapports n'était pas une mauvaise option. Donc, pour conclure, le n ° 3 est techniquement la meilleure option, mais le n ° 2 est probablement l'option la plus réaliste et la plus réaliste si l'on considère le temps et la qualité pour des besoins complexes de reporting et de recherche.