I just finished reading the objective-c developer handbook from apple. So I pretty much know everything that there is to know about objective-c (hee hee). I was wondering how do I go about designing a 3-tier application in objective-c. The 3-tiers being a front-end application in Cocoa, a middle-tier in pure objective-c and a back-end (data access also in objective-c and mysql db).
I'm not really interested in discussing why I'd need a 3-tier architecture, I'd like to narrow the discussion to the 'how'.
For example, can I have 3 separate x-code projects one for each tier? If so how would I link the projects together. In java, I can export each tier as a jar file and form the proper associations.
Thanks!
I think I figured out how to do this...use a static library for the middle and back-end tier use a Cocoa app for the front end.
Related
I've been reading on Wikipedia and it seems that NeXT developed an object-relational mapping framework for Objective-C called Enterprise Objects Framework. And then Apple absorbed NeXT and EOF became WebObjects. And then WebObjects became Java.
Is there any part of the EOF or Objective-C based WebObjects lying around? An object-relational mapping framework for Objective-C would be immensely useful to me.
UPDATE: I'm looking for a database agnostic ORM system that can connect to MySQL and SQLite at least, Oracle and PostgreSQL would be nice. I need to be able to update the database separately from the ORM, something CoreData does not allow.
I'm pretty sure you're looking for Core Data.
From wikipedia:
On computer systems running Mac OS X and mobile devices running iOS,
Core Data is an object graph and persistence framework provided by
Apple. It was introduced in Mac OS X 10.4 Tiger and iOS with iPhone
SDK 3.0. It allows data organised by the relational
entity–attribute model to be serialised into XML, binary, or SQLite
stores. The data can be manipulated using higher level objects
representing entities and their relationships. Core Data manages the
serialised version, providing object lifecycle and object graph
management, including persistence. Core Data interfaces directly with
SQLite, insulating the developer from the underlying SQL.
There is also the GNUstep GDL2 and SOPE GDL1, two related EOF look-a-likes. Not sure how much work would be involved in porting them to OSX.
There are a lot of companies still using WebObjects. EOF is WebObjects' ORM layer which virtually eliminates the need to manually write SQL. Unfortunately WebObjects, and therefor EOF, were ported to Java years ago.
I know you are looking for an Objective-C (or now, Swift?) solution but for RDMSs like MySQL, Oracle or Postgresql, anything that will run them will be capable of running Java as well and WebObjects will run on any platform that supports Java 1.4 or later, including "Cloud" deployments on Amazon, Azure, etc.
Java WebObjects 5.4.3 is available as a free download from Apple. There is an active developer community that has picked up where Apple's development left off and even holds yearly developer conferences.
Bug fixes and new features are being added regularly to WebObjects via Project Wonder, an open-source set of frameworks built on top of WebObjects.
Apple itself does not offer support and has not released any new versions to the public since 2008, however you can see by the URLs used by many of Apple's services such as the App Store, iTunes Store, etc (...apple.com/cgi-bin/WebObjects/...), it's still alive and well inside Apple.
EOF has become CoreData and CoreData doesn't support arbitrary schemas or backing stores. So I made a couple of frameworks that do.
ORDA, the Objective-C Relational Database Abstraction framework, is a 'standard' interface for creating Objective-C database drivers. The goal is to build a system for Objective-C that serves the same purpose of the JDBC.
CORM, the Objective-C Object Relational Mapping framework, leverages Cocoa technologies to provide a powerful, dynamic, and extremely simple to use ORM for Objective-C. It is currently under development.
I heard someone say that developing on the mac using cocoa is great for rapid development.
Is it a good framework for building GUI based apps relatively fast?
Here's for some historical perspective:
The Cocoa framework evolved from the NeXTSTEP framework when Apple bought NeXT (and Steve Jobs along with it) to form the basis of OS X. This is why you see lots of NS littered throughout Cocoa. And NeXTSTEP was one of the earliest frameworks to call itself a RAD framework. So from that point yes, Cocoa is a RAD framework.
There was a famous demo of how fast you can develop apps in NeXTSTEP where a full-fledged text editor (with font selection, file load/save, everything) was developed during the course of the demo (I believe it was under 30 minutes).
Another famous use of NeXTSTEP was the invention of the World Wide Web. Basically HTTP and HTML. Legend has it that Tim Berners-Lee cooked up HTTP and HTML and prototyped the worlds first web browser and web server in just a couple of days. And remember, that first web browser had the ability to edit as well as view HTML -- yes, the original internet was a giant Wiki!
Even at the time it was released as Cocoa around 96/97 it was still considered one of the top RAD environments around. This was around the time Borland was heavily positioning Delphi as a RAD environment and Microsoft's MFC was painful to use in comparison.
These days I would say that it is roughly comparable to .Net. Though I personally feel (and I know lots of long-time Cocoa programmers tend to share this sentiment) that Cocoa still has an edge in how fast I can take an idea to completion and how clean the resulting code is. It's an older framework, more mature and implemented lots of things right but other frameworks have had lots of time to catch up.
I strongly believe the combination of Interface Builder and Cocoa makes prototyping an application faster than anything else I've used. Typically, creating something that is 'visible' takes just a few minutes using IB to wire controls to code, and a few more to write the code itself. Factor in the modular nature of View Controllers and the process of adding GUI elements to a large codebase is suddenly very easy. The next version of Xcode makes this process even faster, so I daresay you've got a lot to look forward to.
If you are familiar with the tools and willing to work with the provided UI elements then I think so. However because you're working with a fairly rich and stateful UI once you decide that you need custom views then you have signed up for some real work.
Overall I find web development slightly faster, largely because there's a wider selection of available libraries and frameworks to build on, but that's only an alternative for certain types of applications.
Is OpenSwing a good framework for developing professional desktop application?
I was recently using the OpenSwing Framework. I can say only the best for the functionalities which are provided with the framework. It is a multitier concept with excelent data binding possibilities. My App uses a small Derby DB in background and I’m managing it with hibernate.
I’m sure, you will be able to advance very fast and provide a working prototype very quick. I would advice you to read the available doc first and to run the provided examples (http://oswing.sourceforge.net/).
However, it has another side which you should be aware of and you will probably notice by yourself if you run the examples. The GridFrame, GridFrameControler, DetailFrame, DetailFrameControler etc classes are not really generic. There are a lot of dependencies bult in and you will have to customize them again and again for every single implementation (can be seen in the demos).
I had another approach, I invested some time in building my own classes which are generic and using the unchanged OpenSwing classes in the background first. Now I’m only setting the properties file where all details are pre-defined. The rest is generic and I don’t have to re-code again and again for every single frame.
I hope this will help.
Regards
I used the openswing in team for more than two years.
It's a pretty nice swing framework for the enterprise development used in the Internal.
It provide great component based by MVP pattern ,such as grid , document ...
If you try it , It's a good article for you about Model-View-Presenter
And try the demo in the source,It's quite good.
The JAllInOne is also a good demo for the framework also made by the mcarniel
and It's a personal project only developed by mcarniel. Thanks mcarniel's great work.
as a Mac outsider it seems that two popular programming languages on the Mac appear to be Objective C and Ruby.
From what I understand the main API Cocoa seems to be written in and optimized for Objective C, but it is also possible to use Ruby for that.
Are there different areas where each language is ideal, for example, I could imagine Objective C could be ideal for a GUI layer, or standalone desktop app, and Ruby could be good for web services etc. What about classic business logic, or data access layers?
What language would be a good choice for a library of services for example? Can we write a library in one language and link to it from a main program written in the other language?
If I wanted to write a layered enterprise application using domain driven design and dependency injection which languages could support each concerns? Are things like DDD and DI common amongst Mac devs?
Just a curious outsider.
If I were to write a big application, I would stick to Objective-C only. It’s not hard, it’s the most supported option and for the foreseeable it will stay that way. As for Ruby, there used to be Java support in Cocoa that does not exist anymore. I’d hate to have a large legacy application written in mixture of Java and Objective-C and having the prospect of rewriting the Java parts or sticking with older OS.
(The previous paragraph applies to writing pure desktop applications. If you wanted and could write a part of the application say as a local webservice it would be quite different, as the Ruby support there would be much more dependable. Depends on your people, experience, goals and other variables.)
Dependency Injection and DDD are both abstract ideas, so yes, you can certainly do that in Cocoa. I have no idea about how many Mac devs do it. As for DI, there is strong support for loose coupling in Cocoa and the whole technology stack (see Interface Builder, KVO/KVC or bindings).
Hope that helps.
I am developing a cocoa application that will be making heavy use of both web services and a standard dbms (most likely MySQL) and I am wondering if anyone has a good option for a database library or ORM solution they have used. CoreData is not an option due to the need to support a standard DBMS and to be able to modify the data outside of the normal application operation.
I have found a number of possible options from new open source libraries:
http://github.com/aptiva/activerecord/tree/master
To writing my own wrapper for the C MySQL api.
Any advice is welcome,
Thanks!
Paul
We faced a similar question when we first started work on Checkout, our solution was to code the entire app in Python, using PyObjC. Checkout 1 had an sqlite backend, Checkout 2 has a postgres backend.
There are a couple of really mature and powerful ORMs on the Pyton side, such as SQLObject, which is pretty simple to work with (we used it for Checkout 1.0) and SQLAlchemy, which is more powerful but a bit harder to wrap your brain around (we used it for Checkout 2.0).
One approach you could evaluate, is building the application in Objective-C, but writing the data model and database connectivity/adminstration code in Python. You can use PyObjC to create a plugin bundle from this code, that you then load into your app That's more or less the approach we took for Checkout Server, which uses a Foundation command-line tool to administer a postgres server and the databases in it, this CLI tool in turn loads in a Python plugin bundle that has all of the actual database code in it. End-users mostly interact with the database through a System Preferences pane, that has no clue what the database looks like, but instead uses the command-line tool to interact with it.
Loading a plugin is simple:
NSBundle *pluginBundle = [NSBundle bundleWithPath:pluginPath];
[pluginBundle load];
You will probably need to create .h files for the classes in your bundle that you want to have access to from your Obj-C code.
You might also want to check out the BaseTen framework. It is a Core Data-like framework (in fact, it can import Core Data models), but works with PostgreSQL (though not MySQL, as far as I know). It includes some very nice features such as schema discovery at run time. It also includes an NSArrayController subclass that automatically handles locking and synchronizing across multiple users, so you can continue to make use of Apples Key-value Binding in your UI.
I have personal experience with this particular problem. I even started down the road of writing my own wrapper for the C MySQL API.
The eventual conclusion was: Don't!
The solution that worked in my case was to communicate with the MySQL server via PHP. If you are familiar with web services, chances are that you know about PHP, so I don't won't go into loads of detail about that.
To read from the database:
The cocoa app sends a request for a URL on the server: http://theserver.com/app/get_values.php
The get_values.php script handles the database query, and returns the data in xml format
The cocoa app loads and parses the xml
To write to the database:
The cocoa app sends a more complex request to the server: http://theserver.com/app/put_values.php?name="john doe"&age=21&address=...
The put_values.php script parses the input and writes to the database
The beauty of this solution is that PHP is great for working with MySQL, and cocoa has some handy built-in classes for working with XML data.
edit: one more thing:
One of the key things you have to figure out with this approach is how much processing should be done on the server, and how much should be done in the app itself. Let cocoa do the things that cocoa is good at, and let PHP and MySQL do the things that they are good at.
You could write a generic PHP script to handle all queries: perform_query.php?querystring="SELECT * FROM .....", but that is hardly an optimal solution. Your best bet is several smaller PHP scripts that handle individual datasets for you. In my case, there was one to get the list of users, one to get the list of transactions, etc. Again, it all depends on what your app is going to do.
GDL2 is a nice example, based on EOF.
Instead of reinventing the wheel by writing your own communication wrapper to deal with MySQL from Cocoa, you could try the SMySQL framework (a.k.a. MCPKit), it was part of the CocoaMySQL application that evolved into the Sequel Pro project. It works with varying versions of MySQL, and seems to be quite robust.
If you need to understand how to incorporate it into your application, there's not much documentation around, but it has an easy to understand interface and you can see it working by looking at the source of Sequel Pro, which is downloadable from Google code.
There is also the CocoaMySQL-SBG fork of the CocoaMySQL project, but that seems to be out of date and I couldn't get it to build properly.
I've also implemented a simple object persistence framework based on sqlite, but it certainly wasn't trivial to do. I agree with eJames' conclusion- don't implement one yourself if you don't have to.
If you aren't committed to programming in Objective-C you might want to take a look at PyObjC which would allow you to program the database portion in Python. You can use the MySQLdb module for DB access and there are plenty of tutorials online for its use. It isn't hard to stuff the data back into Cocoa/CF classes and pass them back to your app.
The main caveat with PyObjC is that at the moment it doesn't work with Tiger.