<< LLBLGenpro does. I would tend to think that any decent mapper would... Where's the definition? I'd like to read more on the subject. >> Indeed, a perfect example where code generation is beneficial. LLBLGenpro can be a better solution than Entity Broker.
But then Entity Broker is extremely good :)
>>THough you may not realize this, this is really true. Because his correction was dead on. What? >>No, it is totally wrong. No wonder you do not value O/R mappers - you have no clue what >>they CAN do. I've been using one for 6 months!!! I value them incredibly!!!
Who are you talking to? What are your presuppositions? >>Powerfull mappers start with the OBJECT MODEL Do I create an object model first?? YES, do I then generate the data model??? YES!!! Then do I generate code from my Data model... Again, yes I do... Then
do i add the additions that have been developed in my object model? YES. Does my O/R mapper create an object model from my relational DB??? Yes it does. Is it complete? No, of course not. Does this work? Yes, it does. I know XPO allows you to do what you're
mentioning. While it's a nice feature, I think that XPO's API is prohibitive and more convoluted compared to LLBLGenpro's (the one I use)...
::>>an o/r mapper doesn't generate code by definition :: ::LLBLGenpro does. I would tend to think that any decent mapper would... Where's the ::definition? I'd like to read more on the subject. Logic 101 for beginners: you can not turn every sentence around.
O/R mappers do not generate code per definition does NOT mean O/R mappeers are not allowed to generate code. It means O/R mappers do not HAVE to generate code. This is true. EntityBroker 2003 did not generate any code, yet it was a O/R mapper way more powerfull
than LLBGEN pro. Especially in the java world a lot of mappers do not generate code. Sadly, their method (bytecode manipulation at class load time) is not something we can do in .NET.
Back to Scotts question regarding DAL and ADO.NET Command Builder. I think Scott was asking was does he; Dynamically build the SQL for the Command Builder? Does he Hard code the SQL for the Command Builder? Does he call SQL stored procedures from the Command
Builder? I too would like anyone’s views on this ...
With reference to the DAL am I right in thinking that the DAL doesn't map directly to the tables on a relational DB (As I thought it did) but could map to 1 or many tables on a relational DB, e.g. the object 'Agent' could refer only to the table [Agent] or
it could refer to many tables that make up the entity of an Agent, e.g. Agent detail from one table, Agent Location from another table, etc. (all joined via a one to one relationship)? Regards Billy
>>Logic 101 for beginners: you can not turn every sentence around. Huh? What is Logic 101? >>yet it was a O/R mapper way more powerfull than LLBGEN pro I've tried EntityBroker out as well... I don't agree... can you quantify your statement? Since entitybroker
is your commercial product, I would be very surprised if you DIDN'T say it was better... but how? I'll switch over if you can prove it to me...
::I've tried EntityBroker out as well... I don't agree... can you quantify your statement? Sure. * Support for data driven inheritance. * Support for remoted scenarios. * Support for database generation (ok, brand new) * Support for dynamic composition of the
persisted object model. Means: an EntityServer can handle objects from multiple DLL's that are determined when it is instantiated - so you can do an application that is extensible. We do it all the time - we ask a helpoer method which dll's in the app dir
have persisted objects, and then instantiate a server over them. * Support for prefetches - LLBGEN does not have this as far as I know. This can significantly take out SQL statements. * Support for caching. You need more? ::but how? I'll switch over if you
can prove it to me... Done. Where is your order?
::I'd be forced to assume then that LLBLGenpro has no additional features that EntityBroker ::doesn't have? Absolutly not. TLLBGEN Pro is way easier to get into, ahs a nicer interface etc. Frans' focus was ease of use, ours was power. He was, in his features,
driven by the user interface - we stil lstruggle on how to expose certain features without overloading the user interface. Heck, we have about half a dozen FLAGS you can set on every field, in addition to stuff like behaviors. But you did not ask for ease
of use. You asked about power. And there we kick LLBGEN pro pretty low in areas.
Dave Wells
Member
310 Points
62 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 01:50 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 02:00 PM|LINK
Systems Architect
thona
Member
20 Points
2923 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 02:47 PM|LINK
a7awo
Member
205 Points
41 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 03:10 PM|LINK
a7awo
Member
205 Points
41 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 03:15 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 03:24 PM|LINK
Systems Architect
thona
Member
20 Points
2923 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 04:40 PM|LINK
boyd5
Participant
1033 Points
226 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 05:16 PM|LINK
Systems Architect
thona
Member
20 Points
2923 Posts
Re: ADO.NET Understanding / Position in Architecture
Jun 09, 2004 06:26 PM|LINK