I think I know what you are trying to do, I cannot comment on the Linq
stuff,
I understand it cause Ive created my own attribute driven data access
framework but all that select stuff I leave to the DB.
Anyway, my presumtion is you are tring to do something similar to what I
have done before.My particular case was Orders (Provisioning, cacelation
etc
etc) all with similar but differing properties.
My advice is do not use an interface for anything other than behaviour,
an
abstract class is much better. From what u have said your Facitiy class
should be abstract and your room and theatre classes should derive from
that
class. This will stop you having to constantly redefine generic
properties
and methods.
Ahhh but this is where linq fails big time if I recollect, it cannot see
inherited properties..Hmmmm..Yeah that sucks and was why I stopped
reading
about Linq. My model base class I used for years would not work with it
(id,
datearchived fields generic to all my tables), and i will stick to what I
know works.
This goes back to what I said previously Linq sucks with OO in mind, it
just
so clearly reperesents table structure rather than the OO view of the
world.
Anyway what I did with the orders was to abstract my different order type
tables with stored procedures. So for a list of all orders just pull up a
list of orders showing only the common properties (Select from orders) ,
then
if clicking on a order say look at the order type property in a factory
to
determine which order type to load call the relevent stiored proc that
links
a generic order table with the concrete order table (select from order
join
concreteorder on....). I don't think you can do this with Linq.
If you can you will prolly need to create a data model that uses the linq
model as a datasource maybe entity <> LINQ <> SQL would do it. But at
this
point sounds like more work than creating a custom DAL to me.
It maybe worth you looking at CSLA unless you are looking to utilise SOAP
then that has some limitations too, or biting the bullet and creating an
in
house DAL/data provider framework.
:
Thanks for your help.
I think the code snippet is suffiicent (in part I have largely changed
the
testing code already), but my intention maybe unclear:
The snippet is exactly the coding that is working now as :
Return type is System.Data.Linq.Table<Room> for var q=from f in
db.Rooms
select f; and
System.Data.Linq.Table<IFacility> for var q=from IFacility f in
db.Rooms
select f;
My intention is to create a single List of different type of objects,
where
all the objects are instantiated from a single or multiple database
tables,
and that the class specific functions to the objects can be invoked
easily.
By converting to IFacility, I can actually create a single
IList<IFacility>
that includes a list of Rooms + Theatres upcasted to IFacility (thus a
single LINQ query to work against both Rooms and Theatres). If not
using
this approach, I can maintain separate list of Rooms and Theatres, but
multiple queries are required on each separate list. A last
alternative
is to do an IList<objects> which I am currently exploring.
The reason of using IFacility instead of an actualy object is to hide
the
details of Facility from coders.
Warren
"Peter Duniho" <
[email protected]> ???gco?l¢Do¡Ps?D
[email protected]...
[...]
private void loadRooms()
{
using (FacilitiesDBDataContext db = new
FacilitiesDBDataContext())
{
db.Log = Console.Out;
db.DeferredLoadingEnabled = false;
var q = from IFacility f in db.Rooms select f; //
some
where clause ommited now
rooms = q.ToList();
}
}
It is still not possible to fully understand your use of LINQ. In
particular, what kind of collection is "db.Rooms"?
Based on naming alone, there's a strong hint that in spite of your
using
the interface IFacility, in fact every "f" you get is going to be a
Room.
If that's true, then the solution is obvious: quit using IFacility as
the
type you get from the collection, and use Room instead.
If that's not in fact a correct understanding of your database, then
you'll need to explore some of the other options mentioned. For
example,
instead of "select f", you could replace "f" with a call to a factory
method that converts the "f" instance to an appropriate Room instance
(or
whatever, according to your needs).
As before, without a true concise-but-complete code sample (your
previous
post contained code that was neither concise nor complete), it's not
really possible to fully comprehend the scenario. There's an art to
creating a suitable code sample, but the general rule is: it has to
compile without the addition of anything else, and while you have to
"dumb
down" the code so that it doesn't contain redundant or irrelevant
information (thus ensuring that it's concise), you still need to
preserve
enough of the problem so that there's no ambiguity about what you're
doing.
Pete
