hi. newbie here...i have a number of large complex forms, each of which feeds several related tables. i often need to view an index of each these forms, which will pull several fields from each of the respective related tables and present the data in a gridview. i prefer to use stored procs for data access. how would i model this for any given form, using the tbh architecture? it seems to produce one entity for each table. yet i don't want to populate an entity like that if i only need a couple of fields.

forumuser - it sounds to me like you're making a mistake in your approach. i personally feel that the entities should be directly mapped to a single table. of course, your BLL layer could work with combinations of related tables (in the same way that the order.cs in BLL/store operates. take a look at that (public static int InsertOrder and public static bool UpdateOrder) for inspiration/ideas. other than that, let me know if you find a method to work outside the norm as i'd be interested to see how this works in practice ;)

jimi

http://www.originaltalent.com

thanks jimi. i'll take a look at that. i hadn't read as far as chapter 9!

raising this old chestnut again. i can't help feeling that it doesn't make sense to create say 30 objects, with *lots* of data, when all i want from the database is the ID field of a particular table. why not create a custom object with fields which match the gridview column requirements, create a stored proc to populate the object and bind the gridview. it's all readonly stuff and this would be *infinitely* more efficient than using an amalgam of standard objects, most of whose data i wouldn't actually need at that time.