Re: Whose Fish?

I already replied, but it seems that every third post must be
sacraficed to Google.Kong.

Maybe I should give my arguments numbers, and just say, "Oh yeah
smarty pants, well #635!".

That would be much more in line with your Table Oriented Programming
approach. It would really cut down on the "duplicated responses"!
Codd would be so proud! ;^)

Same as what I did. You just don't don't like the Whose Fish puzzle
because it's harder, so you're trying to degrade it by writing it off
as something below you.

So you claim. It does not resemble the majority of biz projects I have
worked on. I state that with full honesty. If your experience is
different, the so be it. We can agree to disagree on that point. The
reader can apply whichever branch best fits their experience.

I'm sure plenty of comp.object readers have programmed (or are
currently programming) non CRUD business apps. I'd be interested to
see a voting pole. 1) have you ever worked on a non CRUD/Biz app, and
2) what type of project are you current coding.

I would point out that there is a whole subfield of "optimization"
problems in biz, somewhat related to the Traveling Salesman problem,
perhaps something FedEx faces when deciding how to load and move their
trucks. Maybe those are better in objects, I don't know. I haven't
done much of those so don't dwell on them.



Have a good look at Lhotka's CSLA reusable business framework.

I would suggest you provide more detailed links next time, rather than
"Joe Smith at LSFU made something". If you want to encourage people to
take a look at something specific, then refer them to something
specific.

Sorry. His free reusable business framework can be downloaded here:
http://www.lhotka.net/cslanet/download.aspx

And I don't buy your implications that "OO" means loading the entire
contents of the database into an in memory OO DB of composition and
hierarchies. Most database are size prohibitive for that anyway.

Where did I ever say "entire"? I even gave an example of what OO tends
to do to reduce such confusion.

You seemed to imply (or maybe I inferred) that OO is a bunch of
inefficient navigation through collections. I am just saying that the
composed collections are usually pre-filtered from the DB when they
are loaded into an object.

Better, to me, means the assurance that a change won't indirectly
cause other bugs. That means that the code has to be organized in an
intuitive way, as it is with a good object model,

If "intuitive" is our metric, then sets and relational are far more
intuitive to me than OOP's navigational structures. This is partly
because they are more *sift-able* than OO code: I can bring together
and alter my view of factors much more easily. I don't want to see
things how Bill Gates codes them, I want to see them how *I* want to
see them, and making factors query-able acheives that better than any
known technology. It provides a more flexible way of seeing stuff.
Your OO code will stay OO code in one way in one form. (OO code
browsers are clunky navigational query systems.)

I don't understand why you say this. An in memory table is itself a
collection of info. I really don't see the difference between having
two in memory tables with a SalesPerson and his releated Sales vs a
SalesPerson object with its own collection of related Sales objects.
Well, except for the fact that all my data is active: it is self
validating in real time and has its own associated behavior, where as
yours is just passive data. Meaning some junior can't incorrectly
change a field on one of my business objects that is invalid and then
save it to the DB. It just can't happen.

I will hand it to you that datasets take less work to use than
creating an object model. I think it is worth the trade off to create
models so that I can have strongly typed, self validating data
objects. I created my own object code generator though, and there are
plenty of free ones out there that almost completely eliminate the
extra overhead time, creating a best of both worlds scenerio for me.

My view of how I query info may be different than even what ANOTHER
relational weenie wants to see. I am not stuck with his/her view
either. You can't say this about OOP code.

It is the Frank Sanatra paradigm: I WANNA SEE IT *MY* WAY!

I can create my objects to fit any view I want or need for any given
use case. And I can create different views of similar data for
different use cases. Ex, I might load CustomerInfo with read only ID
and Name fields to populate a list.. Then selecting a customer will
pass the ID to an edit page, where I can use that to load a Customer
object with editable fields for all the information, validation rules,
DB update, etc.

This, and more consistency across shops are the two main features of
relational.

The data in OO systems is still saved in the database that other
internal apps can access. Or we can create a webservice layer.

Again, I don't dispute that OO may fit your head. But to extrapolate
your head to everyone else is a mistake.

I know you're not going to change your mind. I'm just defending what
you attack on comp.object on a regular basis.

and the logic is
encapsulated inside those models in an intuitive place. Then it is
easy to see what will be affected by changes.

Better yet if you can do it by querying, or that a non-programmer can
do it by using query tools (such as Query-By-Example) such that the
programmer does not have to be a glorified product clerk.

So you're saying you anticipate all future requirements into an app at
design time such that a programmer is no longer required?

If you could provide a specific change example along with code impact
and how you think about it, that may be helpful. I cannot read your
mind.

I'm not good at coming up with real world examples.. and the last time
I did you said you didn't know enough about the problem domain, so I'm
not gonna waste my time.

You have your mind made up already.

It is not. If you show me OOP kicking P/R's bootie in a clear
objective way, and I'll reconsider.

Man, what is your myers briggs type? INTJ?

Most programming language frameworks are OO, so it behooves most
programmers to be grounded in OO programming concepts.

True, but that is kind of a QWERTY Keyboard argument: we use it
because everyone else uses it, not because it is better.

There is a big difference between what "everyone else" is programming
in (which doesn't affect me), and what the designers of my software
language are doing. Learning OO has helped me tremendously in using
the .net framework.


The projects that do incorporate OO still use a relational DB as
opposed to loading the entire DB into objects.

They still do a lot of DB mirroring. In-App composition & aggregation,
common OO techniques, is a form of mirroring. One generally does not
do this in P/R because one uses queries to "flatten" the view to fit
the particular task at hand.

This is where I think you are applying non-existent conditions of
"what is OO". I think an object model can pre load its objects with
pre-filtered (queried) data, and still be OO (non-P/R). You say that
I am just doing P/R in OO clothes, but when I see your code and all
the case statements, I have to say that my solutions are more OO than
P/R.

Whatever, most of the apps that I've ever worked on only load the data
that is necessary for the current use case. So the data is still
flattened, but it's in objects instead of table structures. At that
point, why does it matter if they are composed? The composition
collection is already flattened.. it just needs databound into a
control most of the time anyway. There is no need to traverse
anything.

This sounds contradictory. May I request some psuedocode?

class SalesPerson
{
public string Name;
public Collection Sales;

public SalesPerson(int id)
{
// Load Name from db
...
// Load related sales
...
}
}

There is nothing to navigate, just load and bind to controls for
viewing / editing.

Although I will say that the next version of C# will have an
integrated query language for querying in memory collections. (yay!)

I also enjoy languages/tools that offer "local queries". They fell out
of favor, but are slowly creeping back, fortunately.

Really? I imagined you would be against an in memory querying
feature.

Sets and relational seem to work pretty well most of the time for biz
apps. OO thinking seems to ignore them.

Really? Not in my apps.



Jordan

.

Relevant Pages

  • Re: Whose Fish?
    ... That would be much more in line with your Table Oriented Programming ... cart structure/object floating around in the app. ... intuitive way, as it is with a good object model, ... I might load CustomerInfo with read only ID ...
    (comp.object)
  • Re: mfc pitfalls
    ... In most MFC apps, you are writing code in that kind ... virtual methods usually work better than callbacks for most ... no syntax in the design for function pointers. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: Whose Fish?
    ... OO can write the same apps with the same ... My view of how I query info may be different than even what ANOTHER ... Most programming language frameworks are OO, ... In-App composition & aggregation, ...
    (comp.object)
  • Re: WWW/Internet 2009: 2nd CFP until 21 September x
    ... If you can decompose the table into multiple tables each of which has no nulls, what you discover is that a null in the combined table corresponds to an absent row in one of the decomposed tables. ... If I knew then what I know now, I would have refused the whole business and gone into a sensible line of work. ... At one time, maybe it was when Dijkstra was active and 'The Psychology of Computer Programming' was a current book, this culture was evident amond C programmers. ... I have some sympathy for Walt's comments on the grounds that I thought more than half of the apps I saw wouldn't have been needed in those businesses if I had been signing the cheques, let alone most of the requirements. ...
    (comp.databases.theory)
  • Re: Multiuser application
    ... RDBMS behind to give him the data ... Imagine the case for large apps with thousands of users and tables of ... > I will make the necessary preparations not to use the Table ... Table components is that they try to load all the records (which is ok ...
    (borland.public.delphi.database.ado)