I'm trying to design a simple Cocoa application and I would like to have a clear and easy to understand software architecture. Of course, I'm using a basic MVC design and my question concerns the Model layer. For my application, the Model represents data fetched on the Internet with a XML-RPC API. I'm planning to use Core Data to represent a locally fetched version. How should the data be loaded initially? I'm reading the Cocoa Design Pattern book, and they talk about a Model-Controller that is centric to the Model. How would that be done?
Thanks!
Your question is sort of open ended so I will give you my take as someone who has gone through the process of redesigning a poorly built application.
The idea for your model is quite simple:
Create a Data Model (this involves creating your Entities, their properties and relationships).
Put code in place to create a Managed Object Context using the Data Model created in step 1.
Fetch your data from the Internet and create NSManagedObjects based on your Data Model
After step three you will have a Core Data representation of your model in memory, which you can use to drive your user interfaces, or save to a persistent store (to file).
The Core Data documentation, covers each one of the above steps in further detail.
Related
Hi i learned web api 2 recently and i am working on a sample project now.I am following layered architecture in my project.This is the flow
controller=>Business Layer=>Data Layer
Now i read some article about the repository pattern which sound better nowadays.
i saw the flow like
controller=>services=>repository
Is there any significant difference between the two flows?
As a beginner which style of architecture should i flow?
Can someone help me to understand these patterns?
When you use services with repository you should make it generic and use Unit of Work (UOW) so you don't repeat yourself with CRUD actions on every entity. Then add some object relational mapper (ORM) like Entity Framework. It is prefered that you also use domain objects for storing your logic there, and make the services return data transfer objects (DTO), because best practice is to keep your services small and clean. Then you also need to include some mapping tool/logic to map DTO to Domain objects.
And you see where this is all going. Suddenly you have far more complexity and obstructions than you need. Because only one thing that customer care about is quality of your product not some fancy architecture.
But as project grow it is much more important to have proper architecture, automatic tests etc. , so it is valid in large projects. If you want to experiment and learn it is great opportunity, but if you have running application in production, i would rather not make that big changes.
TLDR: they are both valid
I am writing a Mac Cocoa application that will manipulate database files, which can be easily be implemented using NSDocument technology, as they relate directly to disk files.
However the majority of the app will manipulate items within this database. When user opens a database item, a new Window should appear to allow the item to be viewed, edited, saved, so the database item doesn't directly relate to a disk file. Note that undo and redo is appropriate here.
Is it appropriate to use NSDocument technology for both database windows and database item windows, or is there a better approach?
I think using NSDocument would be a great choice. It would allow you to take advantage of most of the provided functionality, such as NSDocumentController, undo support, window management, etc. You will have to override some methods, such as loading and saving. It might be difficult to get the "Open Recent" menu to work correctly for these documents (maybe use a custom URL scheme?). The disadvantages of using NSDocument are... none that I can think of. You would have to write everything from scratch, and it would be even harder to integrate them into the rest of the application.
I built my application based on NSDocument - well, actually NSPersistentDocument as it gives access to Core Data services for storing my object graph. It worked great for me and I found no disadvantages.
When you consider working with NS(Persistent)Document you will have to come up with some kind of mechanism to pass the instance of your document to the various controllers you will build to manage the views/windows and their associated data. I implemented this by creating a generic View controller class capable of holding a reference to my instance of NSPersistentDocument. All my view controllers are subclasses of this generic controller and are thus capable of easily accessing Core Data services.
My app manages 15 Core Data entities with volumes varying per entity from hundreds to hundreds of thousands instances. Not part of your original question, but you might want to consider using Core Data for object persistence. I found it to be real time saver while building my app (having worked before with PHP, Java and various DB layers which generally do not contribute much towards productivity).
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
I've found no clear answer so far, but maybe I've searched the wrong way.
My Question is, can Core Data to be used as a Persitence Storage for a Server Project? Where are Core Data's Limits, how much Data can be handled with Core Data and SQLite? SQLite should handle a lot of Data very well according to their website. I know of a properitary Java Persitence Manager with an Oracle DB as Storage that handles Millions of Entries and 3000 Clients without Problems. For my own Project I wonder if I can use Core Data on the Server Side for User Mangament and intern microblogging, texting with up to 5000 clients. Will it handle such big amounts of Data or do I have to manage something like that myself? Does anyone happend to have experience with huge amounts if Data and Core Data?
Thank you
twickl
I wouldn't advise using Core Data for a server side project. Core Data was designed to handle the data of individual, object-oriented applications therefore it lacks many of the common features of dedicated server software such as easily handling multiple simultaneous accesses.
Really, the only circumstance where I would advise using it is when the server side logic is very complex and the number of users small. For example, if you wanted to write an in house web app and have almost all the logic on the server, then Core Data might serve well.
Apple used to have WebObjects which was a package to manage servers using an object-oriented DB much like Core Data. (Core Data was inspired by a component of WebObjects called Enterprise Objects.) However, IIRC Apple no longer supports WebObjects for external use.
Your better off using one of the many dedicated server packages out there than trying to roll your own.
I have no experience using Core Data in the manner you describe, but my understanding of the architecture leads me to believe that it could be used, depending on how you plan to query and manipulate the data.
Core Data is very good at maintaining an object graph and using faults to bring parts into memory as needed. In that manner, it could be good on a server for reducing memory requirements even with a large data set.
Core Data is not very good at manipulating collections of objects without loading them into memory, making a change, and writing them back out to disk. Brent Simmons wrote a blog post about this, where he decide to stop using Core Data for some of his RSS reader's model objects because an operation like "mark all as read" didn't scale. While you would like to be able to say something like UPDATE articles SET status = 'read', Core Data must load each article, set its status property, then write it back to disk.
This isn't because Apple engineers are stupid, but because the query layer can't make assumptions about the storage layer (you could be using XML instead of SQLite) and it also must take into account cascading changes and the fact that some article objects may already be loaded into memory and will need to be updated there.
Note that you can also write your own storage providers for Core Data, see Aaron Hillegass's BNRPersistence project. So if Core Data was "mostly good" you might be able to improve on it for your application.
So, a possible answer to your question is that Core Data may be appropriate to your application, as long as you do not need to rely on batch updates to large number of objects. In general, no algorithm or data structure is appropriate for every scenario. Engineering is about wisely choosing between trade-offs. You won't find anything that works well for many clients in every case. It always matters what you are doing.
I was going through cappuccino. I did not find any details about the data(model) layer. The same exists in Sproutcore. Am I missing something?
In SproutCore the model layer provides full object-relational mapping and manages things like storage, state, querying and back-end retrieval of the data. Cappuccino does not provide a model layer in the same sense, so from what I've seen (e.g. http://github.com/suitmymind/cappuccinocasts-episodes/tree/master/009) you would instead directly send requests to your back-end and then load the results into objects and handle state, querying, etc. yourself.
Like bruz says, Cappuccino is probably more freeform at the data layer than SproutCore. That said, you could plug in Nicholas Small's CPActiveRecord or Raphael Bartolome's Core Data Cappuccino to get a more automated model experience which also manages server connectivity in various ways.