> > > > > 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?
I predate such practices, so denormalisation doesn't have the same
connotation to me.
> Why otherwise butcher
> the
> correct model to cook up some incorrect model?
Logically correct does not often make it pleasant to use.
> 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.
To me the database has a schema, the UI has a 'schema'..the database
schema injects into the UI schema (though much becomes readonly),
updatable fields in the UI schema are mapped back into the database
schema.
Thus the UI is a decoupled 'view' of the 'correct' model.
(I think you agree with this, but you make the transition from database
to objects...I'd prefer to make the transition from objects to objects)
> 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.
Ah...ok....I see where you're coming from.
>
> > > > 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 :)
Ah ok...I haven't had a go yet...it's early days for me and linq.
>
> 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>.
Sounds good...though I'm not quite sure how you would do this? (and
maybe it's a question for another day).
> 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
Thanks, I'll have a play around and see what pops out.
CONFIDENTIALITY NOTICE
This e-mail (and any attached files) is confidential and protected by
copyright (and other intellectual property rights). If you are not the
intended recipient please e-mail the sender and then delete the email and
any attached files immediately. Any further use or dissemination is
prohibited.
While MTV Networks Europe has taken steps to ensure that this email and
any attachments are virus free, it is your responsibility to ensure that
this message and any attachments are virus free and do not affect your
systems / data.
Communicating by email is not 100% secure and carries risks such as delay,
data corruption, non-delivery, wrongful interception and unauthorised
amendment. If you communicate with us by e-mail, you acknowledge and
assume these risks, and you agree to take appropriate measures to minimise
these risks when e-mailing us.
MTV Networks International, MTV Networks UK & Ireland, Greenhouse,
Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions
International and Comedy Central are all trading names of MTV Networks
Europe. MTV Networks Europe is a partnership between MTV Networks Europe
Inc. and Viacom Networks Europe Inc. Address for service in Great Britain
is UK House, 180 Oxford Street, London W1D 1DS, UK.
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
