核心数据和许多业务逻辑的可可应用程序布局(Cocoa app layout with Core Data and lots of business logic)

核心数据和许多业务逻辑的可可应用程序布局(Cocoa app layout with Core Data and lots of business logic)

对于那些看到我的其他问题的人：我正在取得进展，但我还没有把这个方面包裹起来。 我一直在倾吐stackoverflow的答案和网站像可可与爱，但我还没有找到适合的应用程序布局（为什么科学或商业应用程序的例子缺乏？食谱和书籍的例子太简单）。

我有一个数据分析应用程序是这样布置的：

Communication Manager（单身人士，管理硬件） DataController（告诉Comm.mgr要做什么，并检查它接收的原始数据） 模型（从数据控制器接收数据，清理，分析和存储） MainViewController（骨架现在，侦听comm.mgr来显示视图和警报）

现在，我的数据永远不会直接显示在视图上（就像一个简单的实体和属性表），我可能会使用核心图绘制分析结果（一旦我明白了这一点）。 保存的原始数据将是巨大的（10,000点），并且我使用包装在ObjC ++类中的c ++向量来访问它。 vector类还具有使用NSData作为vector的传输的encodeWithCoder和initWithCoder函数。 我试图遵循适当的设计实践，但我迷失于如何将持久存储放入我的应用程序（这将需要存储和查看旧数据集）。

我读过几个消息说，“业务逻辑”应该进入模型类。 这就是我现在拥有的方式，我将它发送给原始数据，然后解析，清理和分析结果，然后将这些结果保存到矢量类的伊娃数组中。 然而，我还没有看到一个Core Data的例子，它的管理对象除了非常基本的属性（字符串，日期）的简单存储之外，他们从来没有任何业务逻辑。 所以我想知道，我怎么能融合这两个方面？ 我所有的分析都应该进入数据控制器并让它管理对象上下文吗？ 如果是这样，我的模型在哪里？ （如果我的数据存储在我的控制器中，似乎打破了MVC体系结构 - 读取：因为这些是矢量数组，我不能不断地编码和解码它们到NSData流中，所以在我将它们保存到磁盘之前需要一个存在的地方与核心数据，他们需要一个地方存在后，我从存储中检索他们并解码他们审查）。

任何建议都会有帮助（甚至在我已经开始的布局中）。 我只是画了一些对象之间的沟通来给你一个想法。 此外，我还没有模型和视图/视图控制器之间的任何连接（现在使用NSLog）。

For those who have seen my other questions: I am making progress but I haven't yet wrapped my head around this aspect. I've been pouring over stackoverflow answers and sites like Cocoa With Love but I haven't found an app layout that fits (why such a lack of scientific or business app examples? recipe and book examples are too simplistic).

I have a data analysis app that is laid out like this:

Communication Manager (singleton, manages the hardware) DataController (tells Comm.mgr what to do, and checks raw data it receives) Model (receives data from datacontroller, cleans, analyzes and stores it) MainViewController (skeleton right now, listens to comm.mgr to present views and alerts)

Now, never will my data be directly shown on a view (like a simple table of entities and attributes), I'll probably use core plot to plot the analyzed results (once I figure that out). The raw data saved will be huge (10,000's of points), and I am using a c++ vector wrapped in an ObjC++ class to access it. The vector class also has the encodeWithCoder and initWithCoder functions which use NSData as a transport for the vector. I'm trying to follow proper design practices, but I'm lost on how to get persistent storage into my app (which will be needed to store and review old data sets).

I've read several sources that say the "business logic" should go into the model class. This is how I have it right now, I send it the raw data, and it parses, cleans and analyzes the results and then saves those into ivar arrays (of the vector class). However, I haven't seen a Core Data example yet that has a Managed Object that is anything but a simple storage of very basic attributes (strings, dates) and they never have any business logic. So I wonder, how can I meld these two aspects? Should all of my analysis go into the data controller and have it manage the object context? If so, where is my model? (seems to break the MVC architecture if my data is stored in my controller - read: since these are vector arrays, I can't be constantly encoding and decoding them into NSData streams, they need a place to exist before I save them to disk with Core Data, and they need a place to exist after I retrieve them from storage and decode them for review).

Any suggestions would be helpful (even on the layout I've already started). I just drew some of the communication between objects to give you an idea. Also, I don't have any of the connections between the model and view/view controllers yet (using NSLog for now).

最满意答案

尽管vector <>非常适合处理您正在采样的数据（因为它支持动态调整底层存储的大小），但您可能会发现，对于已存储的数据，直通C数组已足够（甚至更好）。 这确实增加了一定的复杂度，但它避免了已经具​​有已知和静态大小的数据数组的副本。

NSData的-bytes返回一个指向NSData对象内原始数据的指针。 核心数据支持NSData作为其属性类型之一。 如果您知道数据中每个项目的大小，则可以使用-length来计算元素的数量等。

在采样方面，我建议在收集数据时使用vector <>，并间断地将数据复制到NSData属性并保存。 注意：我用这种方法（ 截断的核心数据NSData对象 ）遇到了一些问题，我认为Core Data不支持NSData数据对象支持的NSData属性的更改，并且可变对象的数据发生更改。

至于MVC的问题。 我建议数据（模型）由Model管理。 视图和控制器可以向模型请求数据（或数据的子集）以显示。 但数据的所有权是与模型。 在我的情况中，可能与您的情况类似，有时候模型会返回删节的数据集（使用Douglas-Peucker算法）。 观点和控制者并不聪明，即使他们对模型的要求可能在这个角色中扮演了角色（图形比例因子等）。

更新

这里是我的Data类扩展NSManagedObject的代码片段。 对于文件系统解决方案，NSFileHandle的-writeData：和用于监视文件偏移的方法可能允许类似（更好）的管理控制。

// 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; }

While vector<> is great for handling your data that you are sampling (because of its support for dynamically resizing underlying storage), you may find that straight C arrays are sufficient (even better) for data that is already stored. This does add a level of complexity but it avoids a copy for data arrays that are already of a known and static size.

NSData's -bytes returns a pointer to the raw data within an NSData object. Core Data supports NSData as one its attribute types. If you know the size of each item in data, then you can use -length to calculate the number of elements, etc.

On the sampling side, I would suggest using vector<> as you collect data and, intermittently, copy data to an NSData attribute and save. Note: I ran into a bit of problem with this approach (Truncated Core Data NSData objects) that I attribute to Core Data not recognizing changes made to NSData attribute when it is backed by an NSMutableData object and that mutable object's data is changed.

As for MVC question. I would suggest that data (model) is managed in by Model. Views and Controllers can ask Model for data (or subsets of data) in order to display. But ownership of data is with the Model. In my case, which may be similar to yours, there were times when the Model returns abridged data sets (using Douglas-Peucker algorithm). The views and controllers were none the wiser that points were being dropped - even though their requests to the Model may have played in a role in that (graph scaling factors, etc.).

Update

Here is a snippet of code from my Data class which extends NSManagedObject. For a filesystem solution, NSFileHandle's -writeData: and methods for monitoring file offset might allow similar (better) management 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; }