Which one do you prefer for Searching/Reporting DataTable or DTO or Domain Class?

Question

The project currently I am working of requires a lot of searhing/filtering pages. For example I have a comlex search page to get Issues by data,category,unit,...

Issue Domain Class is complex and contains lots of value object and child object.

.I am wondering how people dealing with Searching/Filtering/Reporting for UI. As I know I have 3 options but none of them make me happier.

1.) Send parameters to Repository/DAO to Get DataTable and Bind DataTable to UI Controls.For Example to ASP.NET GridView

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

In this option I can simply by pass the Domain Layer and query database for given specs. And I dont have to get fully constructed complex Domain Object. No need for value objects,child objects,.. Get data to displayed in UI in DataTable directly from database and show in the UI.

But If have have to show a calculated field in UI like method return value I have to do this in the DataBase because I don't have fully domain object. I have to duplicate logic and DataTable problems like no intellisense etc...

2.)Send parameters to Repository/DAO to Get DTO and Bind DTO to UI Controls.

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

In this option is same as like above but I have to create anemic DTO objects for every search page. Also For different Issue search pages I have to show different parts of the Issue Objects.IssueSearchDTO, CompanyIssueTO,MyIssueDTO....

3.) Send parameters to Real Repository class to get fully constructed Domain Objects.

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

I like Domain Driven Design and Patterns. There is no DTO or duplication logic in this option.but in this option I have to create lot's of child and value object that will not shown in the UI.Also it requires lot's ob join to get full domain object and performance cost for needles child objects and value objects.

I don't use any ORM tool Maybe I can implement Lazy Loading by hand for this version but It seems a bit overkill.

Which one do you prefer?Or Am I doing it wrong? Are there any suggestions or better way to do this?

Answer 1

I have a few suggestions, but of course the overall answer is "it depends".

First, you should be using an ORM tool or you should have a very good reason not to be doing so.

Second, implementing Lazy Loading by hand is relatively simple so in the event that you're not going to use an ORM tool, you can simply create properties on your objects that say something like:

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

Third, performance is something that should be considered initially but should not drive you away from an elegant design. I would argue that you should use (3) initially and only deviate from it if its performance is insufficient. This results in writing the least amount of code and having the least duplication in your design. If performance suffers you can address it easily in the UI layer using Caching and/or in your Domain layer using Lazy Loading. If these both fail to provide acceptable performance, then you can fall back to a DTO approach where you only pass back a lightweight collection of value objects needed.

Hope that helps. Steve