NHibernate and Round 2.
I had only planned on writing a blog entry between each major update of Veronica's software so I wouldn't be blogging all of the time instead of coding, but the new framework is working out so well for me now that every major update Veronica asks for are being completed at an alarming rate so while it is only day 2, I'm averaging 2 posts a day already.
So, after being unhappy with the first version and implementing a local version control system I went back to the drawing board for phase 2. I did my homework in chunks, some in the beginning, some in the middle and some after I had a working version running. In retrospect, while I invested many times more hours of research and prototyping this time around, my "version 3" project is proof that I still could have done more, which I will get into in a later post.
I had 3 things I pointed out specifically that went wrong with Version 1, and Version 2 was very much an attempt to deal with all 3 of those things. The first was version control which I solved when I started using Tortoise SVN, the second was my data access model and lastly was my dependence on technologies I've used before.
As I stated in my blog on Version 1, one of the problems I knew I had was how I was communicating with and using the database. Manually persisting my database to my objects was completely painful. I knew about Hibernate from university, but somehow NHibernate had escaped me entirely. I'm flabbergasted that a .Net port of Hibernate existed without my knowledge. I only found this out because one of the projects in the office I'm working on "sort of uses it" (maybe I'll explain the differences in a later post).
So, one day I sat down and read through some docs and built some prototypes, and needless to say, I was completely pleased. One of the biggest issues with my original design was simply the number of places I needed make a change when I modified the database. With NHibernate I simply needed to modify the object itself, a mapping file and the database.
This was infinitely better than my homegrown solution but still wasn't perfect... while I wanted to use SQLite and other open source projects, I also didn't want to be tied down to a single database. While NHibernate will connect to numerous databases, I didn't want to manually create the DB's for every single one. I knew the mapping files had at least enough information to generate a basic DB schema and figured there would be a 3rd party application to generate the DB from the mappings. I was half right. There was software for it, but it wasn't 3rd party. The NHibernate dll has in the rather cryptic namespace NHibernate.Tool.hbm2ddl a class called SchemaExport. This little gem can generate a script to a file, execute the script against a database or both! So now DB manipulation was down to just needing to change the objects and mappings to get a database and persisted objects.
While I did a lot of researching on that topic before starting. Once I found SchemaExport I was just too excited to not dive right into and start on version 2. My code was much better laid out and much more stable and I was incredibly happy with how it was coming along and how quickly it was getting there. I was still using Windows Forms (hadn't done any research on alternatives yet) and eventually I hit the point where I needed to start plugging in a reporting engine.
At this point I think I walked away for days. It was a completely depressing research adventure. Jasper reports was primarily aimed at Java and seemed complicated anyway, Crystal wasn't open source and wasn't a small implementation task, FYI Reporting never seemed to want to work on my machine and SSRS was also not free and even more complicated than Crystal. There were others I passed by that suffered from a myriad of the above flaws and I was determined not to end up in the same boat as with version 1 with a weak implementation on expensive software that simply wasn't even working well.
Around this point a couple fires were lit under me. HST was coming up soon and Veronica's existing license was expiring. 2 very good reasons to get myself in gear and start on something Veronica could use when those things hits her. So I spent several hours researching every possible design venue I could think of when I FINALLY stumbled across this project:
http://wpfreports.codeplex.com/
I had thought that I was hoping for too much and that no one could share my "vision". The open source community is once again my saviour. They are using WPF to design templates and a little bit of custom code behind the scenes to convert essentially a WPF window into a printable document. As an added bonus, anything generated in this fashion can be previewed in the .Net Document Viewer control. I just needed the ability to print, but being given freely the ability to preview as well was beyond what I could have hoped for. It was simple, it met my needs and it was free. In WPF like fashion, the reports are designed in XAML, and the code to populate it can be done behind the scenes in a c# code file. Why isn't every reporting tool done similarly? Now that I've found this, I have no clue.
Now we also hit the reason why I like Open Source projects. There was one thing I could live without but which I was really hoping to be able to do... one of the "reports" Veronica needed was a receipt that comes off a roll of thermal paper. Because it is a continuous roll, the cost effective ideal would be to have a report which I could resize on the fly to meet my needs. So, I downloaded the source, dug through the project and added some variables which could be used to override the hard coded page dimensions from the XAML file as needed and voila, I have a custom build which meets both my needs and my wishlist items :) once development plateaus project I plan on revisiting my solution to see if I can auto-calculate the correct page length for continuous rolls and contribute something back to the community if possible.
While I was excited about this new discovery, there were things I had over looked. WPF and Windows Forms don't inherently like each other. So this new WPF didn't want to play nice out of the box. The solution was quick and simple, there is a library System.Windows.Forms.Integration which has an ElementHost that can be added to a Windows Form and can host a WPF window. This was needed for the preview functionality. The reason I brought this up was twofold; 1) in case someone else had hit this quirk and 2) because it opened my eyes to WPF and Databinding.
So as of July 2nd. Veronica has been using version 2 without complaint. Everything is working, all of the technologies it is built on are freely available and being used without violating any licenses. I would say Version 2 is a complete success. She is slowly finding additional features to add, but the improved layout of the code is making updates and changes absurdly easy.
So why a version 3?
- WPF, which will probably get a blog all to itself. While I did in fact look into it before starting version 2 I hit snags and didn't spend the proper time to research them, but now I'm sold on it. I think the superior Data Binding functionality alone will pay off in the long run, as well being up to date on the latest that is available in .Net.
- Fluent NHibernate. Basically an extension of NHibernate that makes mapping simpler, and makes it possible to catch mapping typos at compile time. Additionally, it completely removes the need for the app and web.config code is a nice thing. Getting up and running with NHibernate with this is much faster and more reliable.
- Layout. While my code is much better, having done some of my research and implementation after I had gotten started naming conventions, file organization and other aspects of the project aren't exactly consistent or well laid out.
- Licensing. At the moment, the WPF engine is part of the main application. If I plan on making a business out of this, the reporting engine needs to be externalized, optional and remain open source under the LGPL license. This also opens up an opportunity to expose to use a proxy or similar pattern in between so that other integrations can be developed if I find a better reporting solution in the future.
At the end of the day, things are slowly becoming clearer and the future looks pretty exciting.
So, after being unhappy with the first version and implementing a local version control system I went back to the drawing board for phase 2. I did my homework in chunks, some in the beginning, some in the middle and some after I had a working version running. In retrospect, while I invested many times more hours of research and prototyping this time around, my "version 3" project is proof that I still could have done more, which I will get into in a later post.
I had 3 things I pointed out specifically that went wrong with Version 1, and Version 2 was very much an attempt to deal with all 3 of those things. The first was version control which I solved when I started using Tortoise SVN, the second was my data access model and lastly was my dependence on technologies I've used before.
As I stated in my blog on Version 1, one of the problems I knew I had was how I was communicating with and using the database. Manually persisting my database to my objects was completely painful. I knew about Hibernate from university, but somehow NHibernate had escaped me entirely. I'm flabbergasted that a .Net port of Hibernate existed without my knowledge. I only found this out because one of the projects in the office I'm working on "sort of uses it" (maybe I'll explain the differences in a later post).
So, one day I sat down and read through some docs and built some prototypes, and needless to say, I was completely pleased. One of the biggest issues with my original design was simply the number of places I needed make a change when I modified the database. With NHibernate I simply needed to modify the object itself, a mapping file and the database.
This was infinitely better than my homegrown solution but still wasn't perfect... while I wanted to use SQLite and other open source projects, I also didn't want to be tied down to a single database. While NHibernate will connect to numerous databases, I didn't want to manually create the DB's for every single one. I knew the mapping files had at least enough information to generate a basic DB schema and figured there would be a 3rd party application to generate the DB from the mappings. I was half right. There was software for it, but it wasn't 3rd party. The NHibernate dll has in the rather cryptic namespace NHibernate.Tool.hbm2ddl a class called SchemaExport. This little gem can generate a script to a file, execute the script against a database or both! So now DB manipulation was down to just needing to change the objects and mappings to get a database and persisted objects.
While I did a lot of researching on that topic before starting. Once I found SchemaExport I was just too excited to not dive right into and start on version 2. My code was much better laid out and much more stable and I was incredibly happy with how it was coming along and how quickly it was getting there. I was still using Windows Forms (hadn't done any research on alternatives yet) and eventually I hit the point where I needed to start plugging in a reporting engine.
At this point I think I walked away for days. It was a completely depressing research adventure. Jasper reports was primarily aimed at Java and seemed complicated anyway, Crystal wasn't open source and wasn't a small implementation task, FYI Reporting never seemed to want to work on my machine and SSRS was also not free and even more complicated than Crystal. There were others I passed by that suffered from a myriad of the above flaws and I was determined not to end up in the same boat as with version 1 with a weak implementation on expensive software that simply wasn't even working well.
Around this point a couple fires were lit under me. HST was coming up soon and Veronica's existing license was expiring. 2 very good reasons to get myself in gear and start on something Veronica could use when those things hits her. So I spent several hours researching every possible design venue I could think of when I FINALLY stumbled across this project:
http://wpfreports.codeplex.com/
I had thought that I was hoping for too much and that no one could share my "vision". The open source community is once again my saviour. They are using WPF to design templates and a little bit of custom code behind the scenes to convert essentially a WPF window into a printable document. As an added bonus, anything generated in this fashion can be previewed in the .Net Document Viewer control. I just needed the ability to print, but being given freely the ability to preview as well was beyond what I could have hoped for. It was simple, it met my needs and it was free. In WPF like fashion, the reports are designed in XAML, and the code to populate it can be done behind the scenes in a c# code file. Why isn't every reporting tool done similarly? Now that I've found this, I have no clue.
Now we also hit the reason why I like Open Source projects. There was one thing I could live without but which I was really hoping to be able to do... one of the "reports" Veronica needed was a receipt that comes off a roll of thermal paper. Because it is a continuous roll, the cost effective ideal would be to have a report which I could resize on the fly to meet my needs. So, I downloaded the source, dug through the project and added some variables which could be used to override the hard coded page dimensions from the XAML file as needed and voila, I have a custom build which meets both my needs and my wishlist items :) once development plateaus project I plan on revisiting my solution to see if I can auto-calculate the correct page length for continuous rolls and contribute something back to the community if possible.
While I was excited about this new discovery, there were things I had over looked. WPF and Windows Forms don't inherently like each other. So this new WPF didn't want to play nice out of the box. The solution was quick and simple, there is a library System.Windows.Forms.Integration which has an ElementHost that can be added to a Windows Form and can host a WPF window. This was needed for the preview functionality. The reason I brought this up was twofold; 1) in case someone else had hit this quirk and 2) because it opened my eyes to WPF and Databinding.
So as of July 2nd. Veronica has been using version 2 without complaint. Everything is working, all of the technologies it is built on are freely available and being used without violating any licenses. I would say Version 2 is a complete success. She is slowly finding additional features to add, but the improved layout of the code is making updates and changes absurdly easy.
So why a version 3?
- WPF, which will probably get a blog all to itself. While I did in fact look into it before starting version 2 I hit snags and didn't spend the proper time to research them, but now I'm sold on it. I think the superior Data Binding functionality alone will pay off in the long run, as well being up to date on the latest that is available in .Net.
- Fluent NHibernate. Basically an extension of NHibernate that makes mapping simpler, and makes it possible to catch mapping typos at compile time. Additionally, it completely removes the need for the app and web.config code is a nice thing. Getting up and running with NHibernate with this is much faster and more reliable.
- Layout. While my code is much better, having done some of my research and implementation after I had gotten started naming conventions, file organization and other aspects of the project aren't exactly consistent or well laid out.
- Licensing. At the moment, the WPF engine is part of the main application. If I plan on making a business out of this, the reporting engine needs to be externalized, optional and remain open source under the LGPL license. This also opens up an opportunity to expose to use a proxy or similar pattern in between so that other integrations can be developed if I find a better reporting solution in the future.
At the end of the day, things are slowly becoming clearer and the future looks pretty exciting.
Comments
Post a Comment