Is it feasable to have DAL and BLL layers in a Mac OS X Application?

I am developing a Mac OS X application using Objective-C and Xcode 4 and want to find out the best way of handling data access and undertaking business logic tasks without having to use CoreData.

I am from a .NET MVC background and would normally have my controller call through to a service layer (using a Repository Pattern) to return data that could be mapped 开发者_开发知识库to my View. This would work in a similar way to the traditional Business Logic and Data Access Layer.

However on the Mac most of my reading suggests that my Models and Controllers should share the responsibility of populating the Model with with data and undertake business and validation logic.

This seems to me a little restrictive and goes against the DRY principle as I may need to repeat some data access/business logic operations in other models thus having to write tha same bit of code again.

Therefore is it feasible to have a set of classes or external libraries that undertake business/data access logic (to a SQLite database) that can then be called from any controller? Therefore the Model will only contain data about itself and validation logic? Or does this go against the core MVC principles and ways of building applications on the Mac?

Is there a particular reason not to use Core Data in this scenario? It's highly-optimized for persisting objects to and from the local filesystem. It also performs validation at the model level, results caching, notifications, etc.

What you describe sounds like a good idea to me. Putting your validation and business logic in your model classes is proper use of MVC, and having the data stored in an sqlite database (that the model classes talk to) is a commonly used methodology too.

I'm not sure if we're on the same page with terminology: if you use that design, your classes "that undertake business/data access logic (to a sqlite database) that can then be called from any controller" will in fact be model classes.