Re: Need some advice for integrating a Cocoa and WO app
Re: Need some advice for integrating a Cocoa and WO app
- Subject: Re: Need some advice for integrating a Cocoa and WO app
- From: Gustavo Adolfo Pizano <email@hidden>
- Date: Tue, 5 May 2009 16:37:36 +0200
On May 5, 2009, at 4:07 PM, Gustavo Adolfo Pizano wrote:
If your customer wants a cross-platform "Native" (non web) GUI for
their app, Java Client is an excellent choice, and I'd highly
recommend you at least look at it's potential. Cooca is cooler and
required for an iPhone app, but Java Client, and especially Direct
To Java Client can get you an app running quickly.
Yes Java its cool also, but the company I work for its aimed for the
mac market only, so they want to stick with apple's technologies.
I will keep reading understanding the concepts better, I have just
draw a macro diagram to my boss of how I have in mind (after your
suggestions) how we should structure the development and attack the
problem. maybe I will try to draw it somehow and send it to the list,
if my boss authorize me to do such.
cheers
Gus..
On May 5, 2009, at 3:34 PM, David Avendasora wrote:
On May 5, 2009, at 8:56 AM, Gustavo Adolfo Pizano wrote:
HEHe you are gonna kill me.. I read it already, I will read it
again, concepts not clear still.
Look at the Overview, especially, the "What does Enterprise Objects
do" and the "High-level view of Enterprise Objects" graphic.
You'll see that EOF sits between different data sources (SQL DBs,
LDAP) and the client apps. Note the "Web browser/Web service
consumer" This is where your web app and your Cocoa app fit in the
picture. You'll also see that you can have a Java Client application.
If your customer wants a cross-platform "Native" (non web) GUI for
their app, Java Client is an excellent choice, and I'd highly
recommend you at least look at it's potential. Cooca is cooler and
required for an iPhone app, but Java Client, and especially Direct
To Java Client can get you an app running quickly.
Dave
:'(
Gus
On May 5, 2009, at 2:52 PM, David Avendasora wrote:
On May 5, 2009, at 8:09 AM, Gustavo Adolfo Pizano wrote:
Hello all.
AHA!, Im starting to understand, but have few questions
By having both clients talk to the WebObjects server, you can
consolidate a lot of your business logic in one place - on
the server in, in WebObjects. If they insist on a Cocoa
client talking directly to the SQL database then there is no
common repository of business logic and it will all have to
be written (and debugged!) twice - once for the Cocoa app and
once for the Web App.
the WebObjects server is .... (kinda lost here with so many
server words), because I have the LDAP, the SQL, and now the WO
server? :S..
Here they don't want the Cocoa app talk directly to the DB,
neither the LDAP, so thinks are starting to be clear for me, if
last question gets clear, :S.
I think you better take some time and sit down and read this: http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/About/About.html#/
/apple_ref/doc/uid/TP30001011-CH201-DontLinkElementID_1
or
http://developer.apple.com/documentation/WebObjects/Enterprise_Objects/EnterpriseObjects.pdf
Once you are familiar with how a WebObjects/EOF application is
structured and how the various components fit together, I think
it will become much more obvious how you can make everything work
together.
Dave
you guys are right its better to have only one way to
communicate to the db, and just have to deal with modifications
once at all, not once per application.
I'm with Dave here. Imagine that your boss also want a VB.Net
and a iPhone app that do the same thing as the Cocoa and WO
apps? You would have to write logic for 4 apps and in 3
different languages! By having the WO app as the back-end, and
if you do it right, you can offer JSON, REST, SOAP,
JavaClient, etc. to clients apps, and the clients would be
thin (e.g. with a minimum of logic).
And yes, they told me they want this to be accessible via
iPhone, for the future.
cheers
Gustavo
On May 5, 2009, at 1:47 PM, David Avendasora wrote:
On May 5, 2009, at 7:05 AM, Pascal Robert wrote:
Le 09-05-05 à 07:00, David Avendasora a écrit :
On May 5, 2009, at 6:38 AM, Gustavo Adolfo Pizano wrote:
Hello Andrew:
The project involves a Web app and a cocoa app that both
authenticate over the same LDAP server, and can connect
after to a SQL server(the same one), for different proposes,
like showing an address book, showing, handling financial
stuff, Calendars etc, they hadn't told me much about it but
as far as I understand it's something like that.
So both applications do the the same, over the same servers,
just that one its made for web and the other one to run
natively on os X.
What you are describing here means that the Cocoa app and the
WO app know nothing about each other and they can easily
change each-others data in the SQL database and it is going
to cause you _lots_ of headaches. Both apps are going to have
caches of data and they _will_ get out of sync.
By making the Cocoa client apps talk to the WebObjects server
instead of the DB, then you can greatly cut down on data
synchronization issues because the WebObjects server
application manages all interaction with the SQL database.
By using JSON RPC (or other WebService technolgy) you are
creating two different _clients_ for your WebObjects _server_.
1) Web
2) Cocoa
By having both clients talk to the WebObjects server, you can
consolidate a lot of your business logic in one place - on
the server in, in WebObjects. If they insist on a Cocoa
client talking directly to the SQL database then there is no
common repository of business logic and it will all have to
be written (and debugged!) twice - once for the Cocoa app and
once for the Web App.
The way I usually explain this to customers/clients/employers
is that the amount of work is the square of the number of
independent applications. Having 2 different apps talking
independently to the DB is 4-times as much work as having 1.
Having 3 independent apps is 9-times the amount of work.
Having them both talk to the WO server instead of directly to
the DB eliminates a huge amount of work and risk. It is still
complicated, but much less complicated than both talking
directly to the DB.
I'm with Dave here. Imagine that your boss also want a VB.Net
and a iPhone app that do the same thing as the Cocoa and WO
apps? You would have to write logic for 4 apps and in 3
different languages! By having the WO app as the back-end, and
if you do it right, you can offer JSON, REST, SOAP,
JavaClient, etc. to clients apps, and the clients would be
thin (e.g. with a minimum of logic).
Probably the biggest benefit of having WO be your server is
that you will be able to leverage the most powerful part of
WebObjects: The Enterprise Objects Framework (EOF) which
eliminates almost 100% of the need to write code - especially
SQL - to interact with the database. To me this interaction
(Object-Relational Mapping - ORM) is the most difficult and
risky area of software development.
Now imagine having to recreate this for every different
application that uses the data in your database.
Avoid creating your own ORM at all costs. It will take you a
majority of your development time, and it will not be as good
as what EOF gives you for free.
I will herd goats with Chuck (and allow him to set Beer quotas)
before I ever try to create my own ORM.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden