Lately I’ve spend a few moments with Crystal Reports 8.0 which is included in your vs.net bits. I’m an absolute newbie when it comes to making reports and after seeing members of my team struggling with Word automation I got kind of skeptic towards report solutions. Now my first report is done using the push model. The push model involves passing a DataSet with one or more DataTable and their DataRelation’s defined into your report. The Crystal Reports engine then generates your report processing the data in 3 steps (Process Model). This is mentioned in the SDK as an un-typed report. Which reminds me… once you defined a DataSet to pass into the report, you’ll be able the output a XML file containing data or the scheme and read this into the report designer. I use this technique to enable clients to create their own custom reports against the application. I just supply my customer with the ReportData.xml and ReportSceme.xml (.xsl) and they can start creating! Right, Crystal Reports is a great product, nice object model and you should read this free Crystal Reports book right now.
I’m currently in the process of tying my domain model to user interfaces, but I still need to figure out what those should look and feel like. What I do know is that a fully fledged Model View Controller would be over the top so I’ll be implementing a Mediator pattern in order to loosely couple my objects. I’m currently investigating using the Façade pattern to expose functionality encapsulated in my rich domain model to user interface packages. In the past I’ve used the Façade pattern to get rid of fine grained structures cross application domain (using remoting and such) so for some reason this doesn’t feel like the correct solution… ?service layer?, but I need to factor some behavior in which isn’t exactly what you’d expect from a thin service layer.