I meant to ask this question in the class and missed it. Maybe it's best to ask here so others get the answer as well;



SF creates an strongly typed version of a data row when BO Mapper maps it to the data row. Now in order to get a series of those rows, why doesn't SF create a collection of those rows rather using ADO.Net CurrentData Table as a collection of those rows. This seems to me a hybrid form of dealing with single record and a set of records.



If SF would use collection of BOs, then any control that supports collection can naturally list those items.

And it would be ready for LINQ right out of the box!



Thanks!

..ßen

That is one of the design considerations that will be reworked when we write the next major version of SF.  Unfortunately, since the BOs act like a hybrid, they are not currently as condusive to working with LINQ as a model would be that worked with separate collections and entities. 

The reason we went with the DataTable approach was that the ADO.NET team has spent a great deal of time optimizing the indexing and memory storage of the data (use Reflector and look at the *Storage classes within the System.Data.Common namespace in System.Data.dll).  This allows our business objects to have greater performance searching within the local collection of records than using an ArrayList or a CollectionBase-based collection.

I've been diving into LINQ [again] for the past few says again (just to keep up). Now that I'm learning SF more and more, I'm realizing how much it is in SF that is not in LINQ approach. i.e. The SQLMETAL.EXE or their Visual mapper, creates the DAL layer, but there is nothing in the business layer.



In DDT, you ask DDT to create the SProc for ADD/UPDATE/DELETE for you and the SF Business layer takes advantage of that automatically. In LINQ, you have to create the SProcs manually and call them manually too. I didn't see anywhere that the LINQ BO has any events for validations and business rules.



Thanks for clear answer!



Thanks Ben!

..ßen