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.
Related
I am trying to build an object oriented wrapper, which will wrap API specification; this includes a many structures, events, and APIs.
This API specification will be revised every year, there by releasing new specification; the updates are likely to have newer structures, events and APIs. Updates will also include
Updates to existing structures, events and APIs, the APIs as such does not change but as they take various structures as parameters which eventually have updates
The challenges
The API specification is nothing but an SDK to a lower layer,
what I am trying to build is also an SDK but will be an object
orient wrapper over this SDK.
The requirement is that the users
want Objects and methods and no “C” like structures and APIs
The frequent version change should not have any impact on high level
application and should seamlessly work with any underlying API
version
Older application should work on newer APIs
Newer application should work on older APIs
The last one is a tricky one, what I mean is that the newer application when it sees that it an older version of SDK should somehow transform itself to an older version of API
Is there any design pattern which will help me achieve this task and tied over the frequent changes to internal data and also achieve backward compatibility and forward compatibility?
OS: Windows
Dev Environment : Visual C++
Your problem is too high level to be answerable by a design pattern.
What you are asking for are architectural principles.
These you should base on your well-founded design decisions ("API is backwards compatible using versioning because...") which in turn are based on your requirements (e.g. "Older application should work on newer APIs").
Look into this (a presentation keynote about API design by Joshua Bloch):
How to Design a Good API and Why it Matters
1) All that comes to mind at the moment, if the sdk API involves manual resource allocation:
RAII, or ctor,dtor resource management: https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
2-5) Determine a function decomposition of the API you're building, that becomes expressible in terms of each version tier of the SDK API. Some details on semi-formal function decomposition here (towards the bottom):
http://jfeltz.com/posts/2015-08-30-cost-decreasing-software-architecture.html
You can then take the resulting function compositions and make them construct-able objects if you have to. Don't worry about the final object model until you have a working understanding of the function compositions involved. This is hard at first, but trust me, it is far more powerful than iterating through several possible object model designs.
For C++, you'll probably need to perform #define pre-processing against a scheme of versions for each upstream SDK API, unless your sdk encodes its version in a file somewhere, such that you can do dll loading instead (in which case, this may be Factory design pattern), but I suspect you already knew that.
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.
Me and a friend are going to be working on an iPhone app that is going to be sending and requesting a lot of information from a 24/7 server (a 2009 Mac Mini). There's going to be a lot of realtime information floating around, and we're not sure what a robust database solution for that info would be. We're essentially looking for a db that's really fast and powerful, but still pretty simple to use, especially since we'll be accessing it from Objective-C, which is still pretty new for us. Is Sqlite what we're looking for? A colleague of ours suggested using PostGres, but isn't PostGres pretty dated?
SQLite is great for the iPhone side. Are you asking about that or the server?
Take a look at the Core Data, Apple's native solution for object graph management and persistence. It uses SQLite internally (though you can set different storage type, including in-memory one), and it is very flexible and optimized.
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.