发电机提供什么功能? [英] What features does mogenerator provide?

查看:151
本文介绍了发电机提供什么功能?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经使用mogenerator一段时间了,虽然有合理的入门指南 Stack Exchange文章在命令行选项,我还没有找到一个很好的指南,它提供的所有功能。
简而言之:除了Core Data为您提供的类之外,什么是什么,mogenerator实际生成的是什么?



坦率地说,我不断发现在标题/实现中没有什么令人愉快的惊喜,我没有意识到在那里,我决定通过mogenerator模板和代码,并记录我在堆栈交换Q& A。我想爱)

解决方案

除了它的两个类系统的核心功能,mogenerator可以帮助你通过在您的机器头和实现文件中自动实现关于Core Data的一些最佳实践。



属性访问器



访问实体的属性的方法是mogenerator生成的核心。但是在访问器中实现了一些很好的功能,超出了Xcode类生成器为您提供的功能。



标量访问器



Xcode的内置生成器提供了为原始数据类型使用标量属性的选项。此选项让您选择使用 NSTimeInterval s而不是 NSDate s为日期类型创建属性 BOOL s而不是 NSNumber s用于布尔类型, int16_t 类似)而不是 NSNumber s。



我发现这是令人不安,因为大多数时候我更喜欢原始类型,但不适用于 NSDate s,它比 NSTimeInterval 更有用。所以核心数据给我选择对象,在这种情况下,我会不断地打开的东西,并犯下像 if(myBooleanAttribute)的愚蠢的错误(总是 YES ,因为 myBooleanAttribute NSNumber ,而不是 BOOL )。或者我可以有标量,但在这种情况下,我得到 NSTimeInterval s,我总是必须转换为 NSDate s。或者我可以手动编辑所有生成的文件给我想要的 NSDate s和 BOOL 的组合



另一方面,mogenerator为您提供这两个选项。例如,你将得到一个 myBooleanAttribute getter,它给你一个 NSNumber (为了容易存储在 NSArray )和一个 myBooleanAttributeValue getter,给你一个实际的 BOOL 。与整数和浮点数相同。 (Mogenerator不会产生 NSTimeInterval 存取子:只有 NSDate s。)



类型化的可转换属性



如果你有一个transformable属性,你可以在属性中设置一个特定的UserInfo键(attributeValueClassName)将返回/接受。 (它会正确转发声明类等)。我发现这个文件的唯一的地方是

相反,Xcode代码生成器只会键入这些可转换的属性作为id类型。



验证声明



虽然mogenerator不会自动生成任何验证方法,正确签名作为机器h文件中的注释。似乎在很大程度上是因为历史原因,但它的确意味着,如果你决定在你的人工文件实现中实现它很容易复制和粘贴签名。 (我不会实际取消注释声明,因为你不应该直接调用验证。)



原始访问器



Core Data已经为您提供了原始值的这些访问器,但由于某些原因,它不会将其包含在其Xcode生成的标头中。



获取的属性



mogenerator将为获取的属性生成访问器。就我可以告诉没有办法让Xcode生成器这样做。



助手方法



自动NSFetchedResultsController生成



如果您的实体中有一对多关系,并且将-template-var frc = true传递给mogenerator,mogenerator将自动生成一个方法来创建对与父对象相关联的子对象的获取请求。它甚至自动生成唯一的缓存名称,并隔离 #if TARGET_OS_IPHONE 预处理器宏中的所有内容。



这不符合你的特定需要,它是一个很好的例子如何可以扩展模板。



+ fetchMyFetchRequest:moc _



如果你喜欢在模型中定义你的获取请求,这是一个比硬编码字符串更好的检索方式。



-MyEntitySet



Mogenerator使用KVC的神奇功能,为您的关系提供 NSMutableSet 代理。



+ entityName



需要向 NSFetchRequest 或其他Core Data方法提供实体名称?通过使用返回实体名称的简单方法,很容易避免硬编码的字符串,因为 NSString

c



+ insertInManagedObjectContext:and entityInManagedObjectContext:



避免硬编码实体名称的另一种方法是使用这些帮助方法。



Typed object ids



每个标题和实现还包括一个 MyEntityID 类。它们是只是子类化 NSManagedObjectID 类的空接口和实现。此外,每个模型类都有一个名为objectID的辅助方法,它会覆盖 NSManagedObject 中的标准objectID方法。辅助方法不会将超类的返回值强制转换为 MyEntityID 类型。





其他



子类化一个自定义超类



命令行选项之一是 - base-class:,它允许您指定基类所有生成的类都将继承。这是非常有用的,这样你可以有一个基类,你可以定义方便的方法(给定的Core Data,你可能应该),或者你可以使用一个现成的核心数据工具包,如SSDataKit(或两者)。 / p>

includem



一个简单的小东西,但是如果你指定一个--includem参数,mogenerator会生成一个header文件,其中包括所有模型头文件。



Const所有属性,关系,获取属性的定义

如果您想在PCH中包含所有标题, h2>

结构的extern声明包含在头文件中,该头文件中定义了 NSString 实体。这允许您定义谓词和其他参数,而不会将实体的名称烘焙到字符串中。例如,

  req.predicate = [NSPredicate predicateWithFormat:
@(%K == YES)AND %K <=%@),MyObject.favorite,MyObject.availableDate,[NSDate date]];

(用于命名空间常量的这种类型的结构描述为此博客



const用户信息键/值的定义



类似地,结构体的extern声明在头部中定义,包括键作为struct的成员,并将值作为值。

  NSLog(@用户密钥的用户信息my key is%@,MyObjectInfo.mykey )//将记录myvalue



备用模板


$ b b

关于mogenerator的一个有趣的事情是,在构建mogenerator中,它的作者(Wolf Rentzsch)基本上为Xcode生成的xcdatamodel文件构建了一个通用解析器和模板引擎,所以你不需要使用mogenerator模板。您可以提供一个简单的命令行参数。有很多用户贡献的模板在GitHub网站上。



事实上,你甚至不必使用Core Data。许多贡献的模板允许您基于数据模型生成一系列普通的NSObject模型类。 (所谓的PONSO:普通老对象)。想在Xcode中使用数据建模器,但还有一些其他的持久化机制?



你根本不需要生成对象:另一个有趣的提交模板只是提供了两个不同模型版本的差异。


I've been using mogenerator for a while now, and while there is a reasonable Getting Started Guide and a Stack Exchange article on the command line options, I haven't found a good guide for all of the functionality it provides. In short: what, above and beyond the classes that Core Data provides for you, what does mogenerator actually generate?

(Frankly, I kept finding little pleasant surprises in the headers/implementations that I didn't realize were in there and I decided to step through the mogenerator templates and code and document what I found in a Stack Exchange Q&A. I'd love to see additional answers and edits, however. )

解决方案

In addition to its core feature of a two class system, mogenerator helps you by automatically implementing a number of best practices regarding Core Data in your machine header and implementation files.

Property Accessors

Methods to access the attributes of your Entities are the core of what mogenerator generates. But there are some nice features implemented in the accessors above and beyond what the out of the box Xcode class generator provides to you.

Scalar Accessors

Xcode's built in generator gives you the option of "use scalar properties for primitive data types". This option gives you choice of having Xcode create properties with NSTimeIntervals instead of NSDates for date types, BOOLs instead of NSNumbers for boolean types, and int16_t (or similar) rather than NSNumbers.

I find this infuriating because most of the time I prefer the primitive types, but not for NSDates which are much more useful than a NSTimeInterval. So Core Data is giving me the choice of objects, in which case I will be constantly unboxing stuff and making stupid mistakes like if(myBooleanAttribute) (which is always YES because myBooleanAttribute is a NSNumber, not a BOOL). Or I can have scalars, but in that case, I get NSTimeIntervals that I'll always have to convert to NSDates. Or I can hand edit all of the generated files by hand to give me my desired mix of NSDates and BOOLs.

On the other hand, mogenerator provides you with both options. For example, you will get both a myBooleanAttribute getter that gives you an NSNumber (for easy storage in an NSArray) and a myBooleanAttributeValue getter that gives you an actual BOOL. Same with integers and floats. (Mogenerator does not generate NSTimeInterval accessors: only NSDates.)

Typed Transformable Properties

If you have a transformable property, you can set a specific UserInfo key ( attributeValueClassName ) in the attribute that will specify the class that your property will return/accept. (And it will properly forward declare the class etc.) The only place I found this documented was on Verious.

In contrast, the Xcode code generator will only type these transformable attributes as id types.

Validation Declaration

While mogenerator does not automatically generate any validation methods, it does include the proper signature as a comment in the machine h file. The seems to largely be for historical reasons, but it does mean that it is easy to copy and paste the signature if you decide to implement it in your human file implementation. (I wouldn't actually uncomment the declaration as you aren't supposed to call validation directly.)

Primitive Accessors

Core Data already provides you these accessors to the primitive values, but for some reason doesn't include them in its Xcode generated headers. Having mogenerator include them in its header files makes it much easier to access a primitive value.

Fetched Properties

mogenerator will generate accessors for fetched properties. As far as I can tell there is no way to have the Xcode generator do this.

Helper methods

Automatic NSFetchedResultsController generation

If you have a to many relationship in your Entity and you pass --template-var frc=true into mogenerator, mogenerator will automatically generate a method to create a fetch request for the child objects associated with a parent object. It even automatically generates a unique cache name, and isolates everything inside an #if TARGET_OS_IPHONE preprocessor macro.

Even if this doesn't fit your particular needs, it is a great example of how the templates can be extended.

+fetchMyFetchRequest:moc_

If you like defining your fetch requests in the model, this is a lot better way to retrieve them than hardcoded strings.

-MyEntitySet

Mogenerator uses the magic of KVC to give you a NSMutableSet proxy into your relationships.

+entityName

Need to provide a entity name to a NSFetchRequest or other Core Data method? It's easy to avoid hard coded strings by using this simple method that returns the name of the entity as an NSString.

+insertInManagedObjectContext: and entityInManagedObjectContext:

Another way to avoid hardcoding entity names is to use these helper methods.

Typed object ids

Each of your headers and implementations also includes a MyEntityID class. They are empty interfaces and implementations that merely subclass the NSManagedObjectID class. Also, each model class has a helper method called objectID that overrides the standard objectID method in NSManagedObject. The helper method does nothing but cast the superclass's return value to the MyEntityID type.

The net result: the compiler can catch your mistakes if you ever accidentally interchange your object ids from different entities.

Miscellaneous

Subclassing a Custom Superclass

One of the command line options is --base-class: which allows you to specify a base class that all of your generated classes will inherit from. This is very useful, either so that you can have a base class where you define convenience methods (which, given Core Data, you probably should) or so you can use an off the shelf Core Data toolkit like SSDataKit (or both).

includem

A simple little thing, but if you specify a --includem argument, mogenerator will generate a header file that includes all of your model header files. Convenient if you want to include all of your headers in a PCH, or something some other standard header you include.

Const Definitions of All Attributes, Relationships, Fetched Properties

An extern declaration of a struct is included in the header that has an NSString defined for every attribute and relationship defined in your Entity. This allows you to define predicates and other parameters, without baking the names of your entities into your strings. For example,

req.predicate = [NSPredicate predicateWithFormat:
@"(%K == YES) AND (%K <= %@)",MyObject.favorite, MyObject.availableDate, [NSDate date]];

(This type of struct used for "namespaced" constants is described My Mike Ash on his blog

const Definitions of User Info Keys/Values

Similarly an extern declaration of a struct is defined in the header that includes the keys as members of the struct, and the values as a values. i.e.

NSLog(@"User info for key my key is %@",MyObjectInfo.mykey) //will log "myvalue" 

Alternate Templates

One of the interesting things about mogenerator is that in building mogenerator its author (Wolf Rentzsch) has basically built a generic parser and templating engine for the xcdatamodel files produced by Xcode. So you don't need to use the mogenerator templates. You can provide your own with a simple command line argument. There are lots of user contributed templates on the GitHub site.

In fact, you don't even have to use Core Data. Many of the contributed templates allow you to generate a series of ordinary NSObject model classes based on the data model. (So called PONSOs: "plain old nsobjects"). Want to use the data modeler in Xcode, but some other persistence mechanism? mogenerator can help you there.

You don't even need to generate objects at all: another interesting submitted template just provides a diff of two different model versions.

这篇关于发电机提供什么功能?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆