Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: Kreeg on 6 Mar 2007 09:00 frebe wrote: >>>>>> I have to disagree, there. Now, I realize that your specific beef is >>>>>> with CRUD apps and OO, and I have to agree that there are times -- >>>>>> especially with simple CRUD apps -- that object-relational mapping is >>>>>> overkill. I also think that ORM does have its place. >>>>> O/R mapping is a bad idea also in non-CRUD applications. You are >>>>> hiding predicate logic and set theory behind a network graph. You >>>>> loose a lot of flexibility. >>>>>> However, to say that using arrays/resultsets/datasets in OO "isn't >>>>>> really OO" is not true IMO. Object-relational mapping isn't the "one >>>>>> true OO", and implicating it as such in this context is just building up >>>>>> a strawman for you to attack. >>>>> Please read the previous posts in this thread. There are a lot of >>>>> claims that SQL need to be hidden in a separate layer and that the >>>>> result should be converted from resultsets to objects. You might not >>>>> agree, but this seem to be the common opinion at comp.object. >>>> Hiding the sql is different from storing data in-memory as resultsets. >>>> You can hide the sql through stored procs (or heck even a view if that's >>>> your preference, which it likely is) and still have the application use >>>> resultsets/datasets. >>> Most "OO" people argue that the database schema should be hidden. That >>> is why they can't allow SQL statements in the "business layer". If you >>> use resultsets in the "business layer", this layer is aware of the >>> schema. Obviously I don't agree with this hiding thing, but that seem >>> to be a common opinion. >> Right, and what I'm saying is that the use of resultsets is independent >> from hiding the schema or hiding the sql. >> >> For example, a resultset that contains 'FirstName', 'LastName', >> 'PrimaryAddress' and 'MobilePhoneNumber' and an object that contains >> four properties by those same names still hide the actual database >> schema, in which addresses and phone numbers are stored in child tables >> to the customer table. > > I agree, but I don't think many others at comp.object do. Accordning > to your argumentation, views would also be very useful for hiding the > database schema. A view could return 'FirstName', 'LastName', > 'PrimaryAddress' and 'MobilePhoneNumber' that is joined from different > base relations. If you use views, you don't have to hide SQL for > hiding the schema. > Right. I mentioned views earlier, that they provide the same sort of implementation hiding. They're generally not my preference, but to each his own. >> Like I said earlier, though, I see uses for both domain objects and >> resultsets, depending on the application I'm building. > > Do you have some examples then domain objects are useful? > It's more the opposite, for me, in that the examples of using resultsets are fewer than domain objects. I generally use resultsets in CRUD scenarios, and use domain objects when I need more behavior, such as calculations, etc. Either way my original point was still that, IMO, there's no commandment saying that true OO'ers shall not use resultsets. I could be wrong. If so, I guess I'm not a 'true' OO'er, which I guess I'm okay with. > /Fredrik >
From: topmind on 6 Mar 2007 11:07 Kreeg wrote: > topmind wrote: > > Kreeg wrote: > >> frebe wrote: > >>>>>> I have to disagree, there. Now, I realize that your specific beef is > >>>>>> with CRUD apps and OO, and I have to agree that there are times -- > >>>>>> especially with simple CRUD apps -- that object-relational mapping is > >>>>>> overkill. I also think that ORM does have its place. > >>>>> O/R mapping is a bad idea also in non-CRUD applications. You are > >>>>> hiding predicate logic and set theory behind a network graph. You > >>>>> loose a lot of flexibility. > >>>>>> However, to say that using arrays/resultsets/datasets in OO "isn't > >>>>>> really OO" is not true IMO. Object-relational mapping isn't the "one > >>>>>> true OO", and implicating it as such in this context is just building up > >>>>>> a strawman for you to attack. > >>>>> Please read the previous posts in this thread. There are a lot of > >>>>> claims that SQL need to be hidden in a separate layer and that the > >>>>> result should be converted from resultsets to objects. You might not > >>>>> agree, but this seem to be the common opinion at comp.object. > >>>> Hiding the sql is different from storing data in-memory as resultsets. > >>>> You can hide the sql through stored procs (or heck even a view if that's > >>>> your preference, which it likely is) and still have the application use > >>>> resultsets/datasets. > >>> Most "OO" people argue that the database schema should be hidden. That > >>> is why they can't allow SQL statements in the "business layer". If you > >>> use resultsets in the "business layer", this layer is aware of the > >>> schema. Obviously I don't agree with this hiding thing, but that seem > >>> to be a common opinion. > >>> > >> Right, and what I'm saying is that the use of resultsets is independent > >> from hiding the schema or hiding the sql. > >> > >> For example, a resultset that contains 'FirstName', 'LastName', > >> 'PrimaryAddress' and 'MobilePhoneNumber' and an object that contains > >> four properties by those same names still hide the actual database > >> schema, in which addresses and phone numbers are stored in child tables > >> to the customer table. > > > > You remap them? That is a waste of code if they are pretty close to > > what you remap them to. If not, then you are only using objects as > > glorified associative arrays. > > > > Not sure what you mean by 'remap'. What is a waste of code? The hiding > of the sql through a proc? firstName ==> x.first_name ssn ==> x.soc_sec_num hourlyRate ==> x.payRate etc... If you do what R. Martin suggests, you almost have to do remapping because you wouldn't necessarily know what the schema or query is yet. If you treat the schema or query as a first-class item, then you can have an associative array contain the results and just use the columns instead of have code to explicitly remap schema names to "internal" names. It is automatic, saving code and mapping effort. (If you don't like a name, you can usually use the query to supply an alias, such as an AS clause.) Similar things apply to saving it back if needed. -T-
From: Kreeg on 6 Mar 2007 11:38 topmind wrote: > Kreeg wrote: >> topmind wrote: >>> Kreeg wrote: >>>> frebe wrote: >>>>>>>> I have to disagree, there. Now, I realize that your specific beef is >>>>>>>> with CRUD apps and OO, and I have to agree that there are times -- >>>>>>>> especially with simple CRUD apps -- that object-relational mapping is >>>>>>>> overkill. I also think that ORM does have its place. >>>>>>> O/R mapping is a bad idea also in non-CRUD applications. You are >>>>>>> hiding predicate logic and set theory behind a network graph. You >>>>>>> loose a lot of flexibility. >>>>>>>> However, to say that using arrays/resultsets/datasets in OO "isn't >>>>>>>> really OO" is not true IMO. Object-relational mapping isn't the "one >>>>>>>> true OO", and implicating it as such in this context is just building up >>>>>>>> a strawman for you to attack. >>>>>>> Please read the previous posts in this thread. There are a lot of >>>>>>> claims that SQL need to be hidden in a separate layer and that the >>>>>>> result should be converted from resultsets to objects. You might not >>>>>>> agree, but this seem to be the common opinion at comp.object. >>>>>> Hiding the sql is different from storing data in-memory as resultsets. >>>>>> You can hide the sql through stored procs (or heck even a view if that's >>>>>> your preference, which it likely is) and still have the application use >>>>>> resultsets/datasets. >>>>> Most "OO" people argue that the database schema should be hidden. That >>>>> is why they can't allow SQL statements in the "business layer". If you >>>>> use resultsets in the "business layer", this layer is aware of the >>>>> schema. Obviously I don't agree with this hiding thing, but that seem >>>>> to be a common opinion. >>>>> >>>> Right, and what I'm saying is that the use of resultsets is independent >>>> from hiding the schema or hiding the sql. >>>> >>>> For example, a resultset that contains 'FirstName', 'LastName', >>>> 'PrimaryAddress' and 'MobilePhoneNumber' and an object that contains >>>> four properties by those same names still hide the actual database >>>> schema, in which addresses and phone numbers are stored in child tables >>>> to the customer table. >>> You remap them? That is a waste of code if they are pretty close to >>> what you remap them to. If not, then you are only using objects as >>> glorified associative arrays. >>> >> Not sure what you mean by 'remap'. What is a waste of code? The hiding >> of the sql through a proc? > > firstName ==> x.first_name > ssn ==> x.soc_sec_num > hourlyRate ==> x.payRate > etc... > > If you do what R. Martin suggests, you almost have to do remapping > because you wouldn't necessarily know what the schema or query is yet. > If you treat the schema or query as a first-class item, then you can > have an associative array contain the results and just use the columns > instead of have code to explicitly remap schema names to "internal" > names. It is automatic, saving code and mapping effort. (If you don't > like a name, you can usually use the query to supply an alias, such as > an AS clause.) Similar things apply to saving it back if needed. > Ah, I see. I wasn't talking about R. Martin's approach at all, since I kind of jumped into them middle of this thread. This particular discussion is so thoroughly off on a tangent that it's probably best that we just let it drop :) > -T- >
From: frebe on 7 Mar 2007 00:44 > > Do you have some examples then domain objects are useful? > > It's more the opposite, for me, in that the examples of using resultsets > are fewer than domain objects. I generally use resultsets in CRUD > scenarios, and use domain objects when I need more behavior, such as > calculations, etc. Do you have such example when domain objects would benefit, compared to using resultsets? /Fredrik
From: Kreeg on 7 Mar 2007 11:16
frebe wrote: >>> Do you have some examples then domain objects are useful? >> It's more the opposite, for me, in that the examples of using resultsets >> are fewer than domain objects. I generally use resultsets in CRUD >> scenarios, and use domain objects when I need more behavior, such as >> calculations, etc. > > Do you have such example when domain objects would benefit, compared > to using resultsets? > Sorry. I could probably come up with something, but 1.) I just don't have the heart to do it right now, and 2.) It probably wouldn't be anything new, and uou could probably present a perfectly reasonable case for an equivalent implementation in p/r. Call me lazy, call me not that smart, whatever :-) > /Fredrik > |