Re: Frontbase and WebObjects
Re: Frontbase and WebObjects
- Subject: Re: Frontbase and WebObjects
- From: Robert Walker <email@hidden>
- Date: Fri, 7 Nov 2003 22:06:10 -0500
One of the major features of EOF is it's ability to abstract the
database from your business logic.
Think about it this way; the less your application relies on database
specific features the more reusable your business objects become.
If you design your system with business logic located in business
objects (subclasses implementing EnterpriseObjects) then you can
arbitrarily switch database servers without any ramifications to your
application. If, on the other hand, you place your business logic in
the database server then it locks you to that database. If you ever
need to reuse the business object you are forced to duplicate, or often
rewrite, your business logic for the new database.
This is to be taken as a general rule of thumb, but as experience
proves this cannot always be accomplished. This is the primary reason
that EOF supports stored procedures. Sometimes the business logic,
especially on legacy databases, can be too complex to move to the
business object layer in a reasonable timeframe. This forces you to
call the stored procedures from your application. There are other
circumstances where you may want to use stored procedures, but
generally try to avoid doing so.
In my experience this seems to be a difficult concept for RDBMS
designers to grasp at first, but once you start thinking in terms of
"business objects" it really starts to make sense. Think in terms of
MCV: place the business logic in the Model classes, user interface
logic in the View classes, and "glue" the Model and View together in
the Controller classes.
On Nov 6, 2003, at 10:48 PM, Arturo Pirez wrote:
On Nov 6, 2003, at 12:10 PM, Bob McCormick wrote:
Hi All,
Am wondering what others have determined is the best way to develop
with Frontbase and WebObjects. I've always used Stored Procedures in
times past, now that I'm coming up to speed with WO, I see that this
tool allows several different ways to fetch data including the use of
Cache.
This is strictly my opinion. That is, I don't have any experience one
way or the other to back this up (well only a little).
Try to write your app in such a way that you never need to be aware
of the database. In other words, try to avoid using any of the fetch
APIs.
Get all your data through relationship traversals and in-memory
filtering.
Of course, sometimes the database is the only way to do things. But
if you
really on the database too much then you're missing out on a lot of
what EOF
offers. Stored procedures would be an example of relying on the RDBMS
too much.
-------
WebObjects in Philadelphia. You want a cheesesteak with that?
Visit http://webobjects.meetup.com
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
--
Think Different
Robert Walker
www.robertwalker1.com
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.