Actually… that’s not the case. The best place to start is the data sheet… but NDEF is a data storage format that isn’t necessarily “file” based. NFC Type 4 chips like the DESFire offer “files” you can define on the chip but these are more like applications. They each get an AID (application ID) and a “type”… NFC Type 4 defines a specific AID for type 4 tags under which raw binary data is stored, and the format of that data must conform to NDEF, but it is not at all the only type of file the DESFire can work with, nor is it the only type of data you can store in a raw binary file… it’s just one way you can use DESFire chips.
For example, you can define a 2k file on the 8k xDF2 that is set up as a stored value “purse” file. That AID now will respond to certain commands like increment, decrement, and value… which will automatically increase the purse value, decrease the purse value, and give the balance, respectively. Why would you want this is a binary file where you control the values yourself? Well, you can assign special access keys so one key can load value (increment) and another can decrement… this might be critical in situations where the top-up station is operated by one company and the vending stations are operated by another, and one does not want the keys for the other’s functions.
There are a lot of things you can do with the DESFire chips… so the datasheet is a good place to start.
When it comes to working with the ACR 122U or any other reader for that matter… you will need to explore the world of APDUs… sending commands to the chip and getting responses back. That’s how you work directly with basically any chip at a fundamental level, and it’s no different with the DESFire EV2.