The difficulty comes when you’re using a model in multiple places. The temptation is high to store logic right in your model because it’s a centralized location. Then when new requirements come it you can quickly find your model bending to fit multiple purposes.

I get into those themes a little in my post on MVC (shameless plug). http://www.mindstorminteractive.com/blog/?p=399

You’ll hopefully get to experience the joys of the ASP.NET MVC world soon enough. Once you learn linq and entity framework you won’t miss your cute little xml parser.

That said, if serializing and deserializing your model directly in your View classes works in your application, than so be it. Although, to me, and my limited understanding of what you are specifically working on, that raises a red flag. For example, what if the data source ( whether it be an RSS, a Web Service, etc. ) returned a data structure that was a far cry from the true object models in which you software operates on? And what if there are multiple services that we need to work with?

Generally speaking, I like to handle this in the Model layer of the software. The various Views and Controllers only know of specific OO Model types. What you end up with is an intermediary object that does the serializing and deserializing and interfaces directly with the data service. If you want to collect data from various sources ( as mentioned above ) you can then write additional intermediary objects that de/serialize those structures. But the important part is that the response from those data services is funneled back through those methods into a common set of Model objects. These objects are understood by the softwares VC’s and are not coupled with the data services that their properties are populated from. In a nutshell, while it may be easy to parse the XML straight in the View it will ultimately lead to tighter coupling. Just think of it this way, “What is the the responsibility of the View?”.

Again, great thoughts! I’ll check back here more often. Take care man.

JP