Order Export Architecture

Question

My question is based more on the architecture of building a module rather than anything else. My end goal is to have an export extension which will allow the user to set two variables through the admin configuration. One being the location of the export and two being the format at which it is exported in. Separating the gathering of the order details, the formation of the file to be exported, and the actual export.

I am using the event sales_order_place_after and my observer will call a method which will export the file containing all information of the current order being placed in the file extension chosen. This is where my question stems from. I am using the observer to call a method which is both checking the file type and gathering the order collection. It then calls these classes which extend my own Abstract class allowing the order details to be pulled, and the file details to setup and structure the document into the format chosen.

1. By using an abstract class to pull order details and each file specific to the extension selected for the export implement them, am I breaking any rules or best practices? Should I be using an interface?
2. I am not overriding nor rewriting any abstract classes of Magento except the core model (not declared in config.xml). Does this risk any performance or redundancy in this practice? Am I crazy for attempting it this way? Will it even work?

My philosophy is that (one) by using an abstract class to pull all order information, the files associated to the extension type are only needed if they are selected and (two) the observer is not bloated w/ a bunch of functionality which will not be used.

Does this make sense?

Answer 1

First some general feedback on exports, and observers I guess. Since observers work at runtime they can cause a lot of issues on the performance and page load time. The order process is already pretty slow in Magento and writing to a file or even sending it via FTP somewhere won't make that a whole lot better.

Since you're making a module I'd advice building in a queue. Basically your observer will write to a queue table in the database and a cronjob will do the heavy lifting. This way users are not bothered by whatever happens during exporting.

Regarding your questions. An interface only specifies the methods a class should have, it can't contain any business logic so if the choice is between an abstract class and an interface you'll have to use the former. As far as I know there aren't any best practices regarding this in Magento but as your describing it, it feels a bit overcomplicated.

As for the rewriting, that's always bad practice. It breaks compatibility on upgrades and with different modules. You should be able to make this work without any rewrites.