Cocoa application layout with master data and lots of business logic

Question

For those who have seen my other questions: I am making progress, but I have not yet turned around this aspect. I poured answers on stackoverflow and sites such as Cocoa With love, but I did not find a suitable application layout (why such a lack of examples of scientific or business applications? The recipe and examples of books are too simplified).

I have a data analysis application that looks like this:

Communication Manager (singleton, controls equipment)
DataController (tells Comm.mgr what to do and checks the raw data)
Model (receives data from datacontroller, cleans, analyzes and saves it)
MainViewController (skeleton right now, listening to comm.mgr to present views and warnings)

Now that my data will not be displayed directly in the view (for example, a simple table of entities and attributes), I will probably use the main chart to build the analyzed results (as soon as I find out). The initial data will be huge (10,000 points), and I use the C ++ vector wrapped in the ObjC ++ class to access it. The vector class also has the functions encodeWithCoder and initWithCoder, which use NSData as the transport for the vector. I try to follow the proper design rules, but I get lost in how to get persistent storage in my application (which is needed to store and view old datasets).

I read several sources that say that business logic should go into the model class. This is how I do it right now, I send him raw data, and he analyzes, cleans and analyzes the results, and then saves them to ivar (vector class) arrays. However, I have not yet seen an example of Core Data, which has a managed object that is something like a simple repository of very simple attributes (strings, dates), and they never have business logic. I wonder how I can combine these two aspects? Should my analysis go to the data controller and manage its object? If so, where is my model? (it seems that it destroys the MVC architecture, if my data is stored in my controller - read: since these are vector arrays, I can not permanently encode and decode them into NSData streams, they need a place to exist before I save them on a disk with basic data, and they need a place to exist after I extract them from the repository and decrypt them for viewing).

Any suggestions would be helpful (even on the layout I already started). I just drew the message part between the objects to give you an idea. In addition, I do not yet have the relationship between the model and view / view controllers (now using NSLog).

Answer 1

While vector <> is great for processing your data that you select (due to support for dynamically changing the underlying storage), you may find that direct C arrays are sufficient (even better) for the data already stored. This adds a level of complexity, but avoids copying data arrays that already have a known and static size.

NSData -bytes returns a pointer to the raw data in the NSData object. Master data supports NSData as one of its attribute types. If you know the size of each element in the data, you can use -length to calculate the number of elements, etc.

On the sampling side, I would suggest using the vector <> when collecting data and, intermittently, copy the data to the NSData attribute and save. Note. I had a small problem with this approach ( NSData objects with truncated kernels ), which I attribute to Core Data, which does not recognize changes made to the NSData attribute when it was supported using the NSMutableData object and changing the changed object data.

Regarding the issue of MVC. I would suggest that the data (model) is driven by the model. Views and controllers can query the Model for data (or subsets of data) for display. But data ownership with the model. In my case, which may be similar to yours, there have been cases when the Model returns abbreviated data sets (using the Douglas-Puker algorithm). Representations and controllers were not wiser in that the points were deleted - although their requests to the Model could play a role in this (graph scaling factors, etc.).

Update

Here is a snippet of code from my Data class that extends NSManagedObject. To solve the file system NSFileHandle -writeData: and methods for controlling file offsets can allow similar (better) controls.

// Exposed interface for adding data point to stored data - (void) addDatum:(double_t)datum { [self addToCache:datum]; } - (void) addToCache:(double_t)datum { if (cache == nil) { // This is temporary. Ideally, cache is separate from main store, but // is appended to main store periodically - and then cleared for reuse. cache = [NSMutableData dataWithData:[self dataSet]]; [cache retain]; } [cache appendBytes:&datum length:sizeof(double_t)]; // Periodic copying of cache to dataSet could happen here... } // Called at end of sampling. - (void) wrapup { [self setDataSet:[NSData dataWithData:cache]]; // force a copy to alert Core Data of change [cache release]; cache = nil; } 

Answer 2

I think you might be reading too much in Core Data. I do not understand this so much, therefore I speak as not an expert, but basically there are two categories of storage systems.

At first it is a basic database such as SQLite, PostgreSQL or any number of solutions. They are intended for data storage and retrieval; there is no logic, so you need to figure out how to manage tables, etc. This is a bit complicated, but they are very effective. They best manage a lot of data in raw form; if you want objects with this data you create and manage them yourself.

Then you have something like Core Data that should not be viewed as a database, as well as a persistence structure. With Core Data, you create objects, save them, and then retrieve them as objects. This is great for applications where you have a large number of objects, each of which contains several pieces of data and relationships with other objects.

From my limited knowledge of your situation, I would venture to suggest that a true database may better suit your needs, but you will have to make a decision there (as I said, I know little about your situation).

As for MVC, I believe that the view should contain only the display code, the model should contain only the code for managing the data itself and its memory, and the controller should contain the data processing logic. In your case, it looks like you are collecting raw data and processing it before storing it, in which case you want to have another object to process the data before storing it in the model, and then a separate controller for sorting, managing, and otherwise case, prepare the data before receiving it. Again, this may not be the best explanation (or the best methods for your situation), so take it with salt.

EDIT: Also, if you are looking at getting Core Data more, I like this book . This explains the whole object-saving-against-base concept much better than me.