Chris said:
I'll give you an example. You can't do aggregates over ADO.net data
services, this is a real deal breaker if you are doing some kind of paged
gridview.
I use the Model View Presenter pattern, which means that a control is
using a DTO between the UI and the presenter on the interface and is
never in contact with the BLL directly. The interface can be a
collection of DTO(s) a public List<DTO> DTOS { set; } on the interface,
which can use a Session variable if need be up at the UI.
The code to access the Model via an ADO.NET data service is in the BLL.
The Linq query is only to pull the entities by conditions using the
dataservice. I get the query back where I populate a collection of
DTO(s) using List<DTO> and give it back to the UI on the interface
List<DTO> DTOS.
So, under that implementation, I don't see why you couldn't use a
Linq-2-Object aggregate query against the DTOS, as an example, with DTOS
used as the binding datasource of a gridview.
If you want to have a SP which returns an integer EF can't handle
it because it isn't an entity. I could go on and on.
I don't use sprocs period there is no need to use sprocs, IMO, even
though they can be used with EF.
I spoke directly to the
EF team and these were things that they acknowleged weren't in version 1.
That is why we are avoiding EF and looking at other ORM solutions or rolling
our own. The book you recommended does look really good. I will have a look
at it because I don't really "get" design pattern properly. Cheers for the
advice.
Yes, in this case you would roll your own and can still use ADO.NET Data
services if you think outside of the box. And that CSLA book the CSLA
2003 version I read back several years ago and implemented the CSLA
framework and the project that use CSLA in a learning capacity on my
home machine kicked down the door of what object oriented programming
was about. It started making me think outside the box as to just what
one can do with objects.
BTW that is what I am doing using SP's into data readers into Business
Objects but I don't think you are reading my question properly (or I am
explaining it poorly). What I want to know is that if you have a deep
hierarchy of objects e.g. Customer to Invoice to Order to OrderLine. When
you instantiate a Customer is there a way of saying Get Customer with
Invoices and Orders but NOT OrderLines. Is there some slick way of doing
this without custom methods that say GetCustomerWithInvoices(). In EF you
use the Include keyword. Is that clearer?
I don't know who you are talking about. Are you talking ADO.NET SQL
Command objects or are you talking ADO.NET Entity Framework with using
sprocs?
If it were me doing this, I wouldn't use Linq-to-Entity with sproc period.
I would be using Entity-SQL (ESQL) using a Select statement against the
model for the entity wanted, just like you can do it with an ADO.NET SQL
Command object and T-SQL statements whether or not you're using inline
T-SQL or T-SQL in a sproc.
In this case, I would be using inline ESQL statements.
I would use an ESQL Database reader which is not unlike using a
System.Data datareader to read the returned set of entities.
While in the ESQL database reader loop on the results of returned
entities like Entity.Customer only, then I would instantiate a new
Entity.Customer and populate the Entity.Customer from like fields of the
ESQL Entity resultset for Customer Entities.
And I would return Entity.Customer (an object) populated. Do you understand?
If I were doing the above for Entity.Invoices off of the model using
ESQL, then I would be doing it and returning a List<t> or
List<Entity.Invoices>.
Do you understand? It's OOPs. And an Entity is an object, and it can be
instantiated new as an object and populated individually, not related.
I don't know that you can exclude an entity on a one-to-many using
Linq-to-Entity, other than, removing the link on the EDM graphical IDE
between the parent to the child.
Maybe you need to get this book too that shows examples of using ESQL.
http://www.apress.com/book/view/1590597893
Your biggest problem I think for you is that you don't fully understand
object oriented programming. And again not trying to be smart here, but
most don't know OOPs.