> > > > I don't see the 'obvious' part in that remark. For
> FETCHING,
> > it
> > > > might be handy to have denormalized data in some areas, but for
> saving
> > entities,
> > > > you definitely want to stick to the abstract entity definitions in
> > your
> > > > program's reality, not some denormalized pile of tables.
> > >
> > > UI usually operate on schema's that are derived and
> > > denormalised...though I accept that in MS world this is less true.
> >
> > what does 'MS world' have to do with it?
>
> Because different OO/RDB infrastructures encourage different approaches.
Though, isn't the main cause for doing things 'differently', i.e.
using denormalized tables, because of performance? Why otherwise butcher the
correct model to cook up some incorrect model? For the UI? I think that's not
a good approach: if the UI changes, you're forced to alter your table
structure as well. IMHO not the way to go. If the UI needs lists of data which
is the result of combining sets of data, you should make that transition when
fetching data from the db (using a projection in the query) or by doing the
projection in memory :) After all, linq allows you to join sets of entity
objects in-memory and project it onto new types, in memory.
> > > Generally front end show all sorts of data that is derived or
> > > denormalised from the underlying data, a simple grid map contain several
> > > joins, sometimes it makes sense to display those joins in separate
> > > grids, often not.
> >
> > Though that's readonly data if it's presented in a single set. You
> > can create that easily with linq queries, that's the purpose of querying
on
> > top of a normalized model:
> >
> > var q = from c in nw.Customers
> > join orders o in nw.Orders on c.CustomerID equals o.CustomerID
> > select new { o.OrderID, c.CompanyName};
>
> Correct....but this is a collection of anonymous types...it would be
> much nicer if they were explicitly named....can you use named types in
> the select clause?...I'll have a go.
Yes you can :)
public class MyNewType
{
public int OrderID { get; set;}
public string CompanyName { get; set;}
}
//...
var q = from c in nw.Customers
join orders o in nw.Orders on c.CustomerID equals o.CustomerID
select new MyNewType(){ OrderID=o.OrderID, CompanyName=c.CompanyName};
q is then an Enumerable of MyNewType objects. As you can see, changing the
data in such an object isn't really useful: altering the companyname for
example doesn't alter the company name of the customer.
What's also an option is to add to for example the Order entity class
a property which simply reads/writes this.Customer.<property>.
Keep in mind that this will trigger lazy loading so pre-fetch the
related entities before using it. The advantage of this is that you have the
related customer entity in the graph so you can alter the related entity and
save the whole graph in one go (so the data IS presented as a combined set but
isn't readonly :))
> > you then bind the q to a grid, done. You create new sets using
> > projections. If you want to 'extend' entities to contain data from other
entities,
> you're
> > IMHO
> > not doing yourself a big favor, as the model is then in theory wrong,
> plus
> > you
> > get problems when saving data.
>
> As you say it will have to be readonly...this is fine.
Correct.
FB
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
