Cleaning up procedural import / export program

I am working on an import / export program that can export content from a CMS into a XML structure which then can also be reimported into the CMS in order to 开发者_运维知识库update the content.

Yesterday I came up with a prototype by some explorative coding. The functionality is there, the program works as expected. But the functionality basically consists of 3 methods (one main, one recursive for import, one recursive for export) each spanning over 300 lines. The code consists of some nested foreach and while and ifs and is so procedural as it can be.

Although it works I am a bit worried that the final version of the program will look even uglier because especially in the import method there are many special cases needed in order to convert the XML structure back to database content.

I am wondering how OOP can come to help here. At the moment my approach is generating a tree like structure of DB rows that are serialized to XML and on import the XML again is serialized back to a tree structure based on arrays.

Would it be better to create a tree of objects in order to capsulate behaviour? Actually I find it quite convenient to work with the array structure because PHP is strong in working with arrays and serializing / deserializing them is very easy. Maybe a functional programming style approach is more suitable then forcing in OOP... Adding a complex Serializer that can convert from and to objects seems to me even more bloat.

I know that there is no absolute answer to this, I would be interested in how you structure scripts like mine in order to handle special cases on import / export etc. without creating two huge methods that basically do everything.

---

The problem is that arrays don't implicitly support metadata - and you've already got a difference in types (between atomic and aggregated entities - although that's one seperation which can be described using arrays).

The overriding concern here is that the quality of code you can produce is dependent on your skills and experience - if it were me, I'd probably opt for OO approach to get cleaner code - but if you're not familiar with OO programming then you're battling on 2 fronts - the problem domain and the programing methodology. Having said that, learning new ways of programming is always a good idea - even if you never write OO code again, it will improve your procedural coding.

If you do decide to give it a go, then the simplest starting point is to define an object for each XML tag then build in validation around that.

HTH

C.