Windows Form Controls and LINQ; What should I return?

Question

When working with Windows Form controls and LINQ is there a "Best Option" for how your Buisiness Layer returns the Data?

Right now I am returning DataTables so that I can then set the DataSource to the returned DataTable. Is there a better option? Why?

public class BLLMatrix
{
    public static DataTable GetMaintItems(int iCat)
    {
        IQueryable<tblCaseNotesMaintItem> tItems = DALMatrix.GetCNTable();
        return
            (tItems.Where(item => item.CategoryID == iCat & item.IsActive).OrderBy(item => item.OrderID).Select(
                item => new { item.ItemID, item.ItemDescription })).CopyLinqToDataTable();
    }

internal static class DALMatrix
{
    internal static MatrixDataContext MatrixDataContext = new MatrixDataContext();

    internal static Table<tblCaseNotesMaintItem> GetCNTable()
    {
        return MatrixDataContext.GetTable<tblCaseNotesMaintItem>();
    }

---

I found this similar question --> Separating concerns with Linq To SQL and DTO's

Answer 1

Personally, I prefer Data Transfer Objects, but DataSets work in a pinch.

Basically, the idea is that if you are working with Data Transfer Objects (which have no logic, and represent the model that you are looking to work with on the client), that is an abstraction that can live on regardless of changes on the front or back end. It's typically a good idea.

DataSets are useful, but their lack of compile-time safety (not in the case of strongly-typed DataSets though) because of numeric/string-based field access can pose a problem.

Typically, there is also a large amount of overhead in serializing DataSets over a wire compared to a Data Transfer Object.

Answer 2

I like to create my own model classes because of the overhead of DataSets. If you return an object array (or anything that implements IList interface) you can still set that equal to the DataSource property of most ASP.NET elements.

Answer 3

I personally like to set my DataSources when using links to List<YourObject>

Answer 4

I prefer the Business Logic to return an instance of an object, such as Car, ICar or List(Car) Let the DAL populate the object for you. This way you maintain a clear separation between Data and UI.

Answer 5

I like to use DataReaders rather than datasets, and I'll use an iterator block in the data layer to turn the datareader into an IEnumerable<IDataRecord>. From there, I have a sort of extra step in between the business and data layer to translate that IEnumerable into an IEnumerable<MyBusinessObject>. You should be able to pass this on to the presentation layer for databinding as well.

I like this approach because it does a better job separating the data and business layers: the business layer shouldn't think in terms of datasets, and the data layer shouldn't need to know how to construct business objects. If I think of this as a separate tier I get the best of both worlds. A change to the either the data or business tiers means I only need to change the factory code for that constructs my business objects.