在 Mac OS X 应用程序中拥有 DAL 和 BLL 层是否可行？
我正在使用 Objective-C 和 Xcode 4 开发 Mac OS X 应用程序，并且希望找到处理数据访问和执行业务逻辑任务的最佳方法，而无需使用 CoreData。
我来自 .NET MVC 背景，通常会让我的控制器调用服务层（使用存储库模式）以返回可以映射到我的视图的数据。这将以与传统业务逻辑和数据访问层类似的方式工作。
然而，在 Mac 上，我的大部分阅读表明我的模型和控制器应该共同承担用数据填充模型并承担业务和验证逻辑的责任。
在我看来，这似乎有点限制性，并且违背了 DRY 原则，因为我可能需要在其他模型中重复一些数据访问/业务逻辑操作，因此必须再次编写相同的代码。
因此，拥有一组类或外部库来承担业务/数据访问逻辑（到 SQLite 数据库）然后可以从任何控制器调用是否可行？因此模型将仅包含有关其自身的数据和验证逻辑？或者这是否违背了核心 MVC 原则以及在 Mac 上构建应用程序的方式？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在这种情况下是否有特殊原因不使用 Core Data？它针对在本地文件系统之间持久保存对象进行了高度优化。它还在模型级别执行验证、结果缓存、通知等。
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.
你所描述的对我来说听起来是个好主意。将验证和业务逻辑放入模型类中是 MVC 的正确使用，并且将数据存储在 sqlite 数据库（模型类与之通信的）中也是一种常用的方法。
我不确定我们是否在术语上达成一致：如果您使用该设计，您的类“承担业务/数据访问逻辑（到 sqlite 数据库），然后可以从任何控制器调用” 是模型类。
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.