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

Question

Le projet actuellement je travaille en exige beaucoup de pages searhing / filtrage. Par exemple, j'ai une page de recherche comlex pour obtenir les questions de données, catégorie, unité, ...

Numéro de classe de domaine est complexe et contient beaucoup d'objets de valeur et les objets enfants.

.Je me demande comment les gens traitent Recherche / Filtrage / rapports pour l'interface utilisateur. Pour autant que je sais que j'ai 3 options, mais aucun d'eux ne me rendrait 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 passer par la couche de domaine et base de données de requête pour les spécifications données. Et je ne dois obtenir complexe entièrement construit objet de domaine. Pas besoin d'objets de valeur, les objets enfants, .. Obtenir des données à afficher dans l'interface utilisateur dans DataTable directement la base de données et de montrer dans l'interface utilisateur.

Mais si avoir doivent montrer un champ calculé dans l'interface utilisateur comme valeur de retour de méthode que je dois faire dans le DataBase parce que je n'ai pas entièrement objet de domaine. Je dois dupliquer des problèmes logiques et DataTable comme pas IntelliSense etc ...

2.) Envoyer des paramètres au référentiel / DAO pour obtenir DTO et Bind DTO à l'assurance-chômage des contrôles.

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

Dans cette option est identique comme ci-dessus, mais je dois créer des objets DTO anémique pour chaque page de recherche. Aussi Pour différentes pages de recherche d'émission Je dois montrer différentes parties de la question Objects.IssueSearchDTO, CompanyIssueTO, MyIssueDTO ....

3.) Envoyer des paramètres à la classe Real Repository pour obtenir entièrement construit des objets de domaine.

IList<Issue> issues =issueRepository.FindBy(specs);
//Bind to grid...

J'aime Domaine Driven Conception et modèles. Il n'y a pas DTO ou logique double emploi dans ce option.but dans cette option, je dois créer beaucoup de l'enfant et de l'objet de valeur qui ne sera pas montré dans le UI.Also il a besoin ob de beaucoup se rejoignent pour obtenir l'objet de domaine complet et le coût de la performance pour les enfants aiguilles des objets et des objets de valeur.

Je ne pas utiliser d'outil ORM Peut-être que je peux mettre en œuvre Chargement Lazy à la main pour cette version mais il semble un peu exagéré.

Lequel préférez-vous? Ou 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 ».

D'abord, vous devez utiliser un outil ORM ou vous devriez avoir une très bonne raison de ne pas être en train de faire ainsi.

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;
       }
}

En troisième lieu, la performance est quelque chose qui devrait être considéré au départ, mais ne devrait pas vous conduire loin d'un design élégant. Je dirais que vous devez utiliser (3) s'écarter d'abord et seulement à partir si sa performance est insuffisante. Cela se traduit par écrit la moindre quantité de code et ayant le moins le double emploi dans votre conception.

Si les performances sont amoindries, vous pouvez répondre facilement dans la couche d'interface utilisateur à l'aide Mise en cache et / ou dans votre couche de domaine en utilisant Chargement Lazy. Si ces deux ne parviennent pas à fournir des performances acceptables, alors vous pouvez revenir à une approche DTO où l'on ne passe en retrait une collection légère d'objets de valeur nécessaires.

Answer 2

Ceci est une question grand et je voulais donner ma réponse aussi bien. Je pense que le techniquement meilleur réponse est d'aller avec l'option # 3. Il permet de mieux décrire et organiser les données, ainsi que l'évolutivité pour les futures améliorations de rapports / demandes à la recherche.

Cependant alors que cela pourrait être la meilleure option dans l'ensemble, il y a un coût énorme de l'OMI par rapport à l'autre (2) options qui sont le temps de conception supplémentaire pour toutes les classes et les relations nécessaires pour soutenir la besoins de rapports (encore une fois en partant du principe qu'il n'y a pas d'outil ORM utilisé).

Je lutte avec cela dans beaucoup de mes applications aussi bien et la réalité est que # 2 est le meilleur compromis entre le temps et la conception. Maintenant, si vous demandiez à vos objets busniess et tous leurs besoins, il est pas question qu'un modèle à bien posé et bien conçu est important et il n'y a pas de substitut. Cependant en matière de rapports et de recherche cela me est un animal différent. # 2 fournit des données fortement typée dans les classes anémique et n'est pas aussi primitive que les valeurs dans DataSets comme codées en dur # 1, et réduit encore considérablement la quantité de temps nécessaire pour compléter la conception par rapport à # 3.

Idéalement, j'aimerais étendre mon modèle d'objet pour englober tous les besoins de rapports, mais parfois l'effort nécessaire pour le faire est si vaste, que la création d'un ensemble de classes séparées seulement pour les besoins de rapports est une option plus facile mais toujours viable. J'ai demandé en fait presque identique à cette question quelques années et a également été dit que la création d'un ensemble de classes (essentiellement DTO) pour les besoins des rapports n'a pas été une mauvaise option.

Donc, pour conclure, # 3 est techniquement la meilleure option, mais # 2 est probablement l'option la plus réaliste et viable lorsque l'on considère le temps et la qualité ainsi que des rapports complexes et les besoins de la recherche.