Since I'm diving heads first into refactoring Easy Assets .NET I figured I'd post some messages on what exactly I'm doing, my thought processes behind it, and how I think the application and especially the users will benefit.
Note that I highlight the users. I believe that the amount of work it takes to refactor a project to the extent I am is not an undertaking to be taken lightly. The code I am using for the hosted version is ok mind you, but it is now over a year old, I've come a long way, and I've just learned better techniques for doing things.
So how exactly does one refactor to gain maximum benefit to the users? Here's what I'm shooting for:
End Users
The end users of the application may or may not have IT expertise. When I first designed Easy Assets .NET I designed the User Interface to be very clean and easy to use. There are no screens in this application that present any sort of complexity that will make a user's eyes bug out and I think that's a good thing. That being said, I think I may have oversimplified things in a few places and ended up with a few extra clicks that aren't very helpful. So that brings me to refactoring goal #1:
Refactoring Goal #1: Keep the UI simple and intuitive, but cut down on unecessary clicks and eliminate popups wherever possible.
The second goal of refactoring for the end user is to increase the performance of the application. Granted, I haven't had any complaints about the speed of the application thusfar, but there are a few things I feel that I could do better. The big one that comes to mind is when I developed this application I was in love with the idea of business objects and collections of objects. I was building collections of business objects and binding them all over the place! .NET makes this simple and easy to do and it was neat! However, looping a datareader to fill a bunch of business objects and passing the whole collection back isn't the most performance friendly way of doing things. Also, since sometimes fields shown in grids are child objects of a business object which are lazy-loaded I can end up with extra database calls that really don't need to be happening. That brings me to goal #2:
Refactoring Goal #2: Do not fill business object collections when you do not need to use business logic. Instead I am just tossing a datatable back.
Developers
Well, I'm now going to have two versions of my product, the hosted one for those organizations without the IT expertise or the necessary equipment (servers, SQL Server/MSDE, etc) to use and the local install which I am targeting towards organization that have some IT expertise and the necessary equipment to run the application. This means that my local install version has to be developer friendly! I realized very quickly when looking through my existing codebase that there were a few things I could do to make life easier on developers:
Refactoring Goal #3: Organize your code files! Before I had everything in the root which was fine since there aren't all that many files I know the application inside and out... however I realized that if I was a developer opening this project for the first time there were enough files that I would struggle finding what I was looking for. So now everything is broken into nice layers.
Refactoring Goal #4: Pick a pattern! I am going to be implementing my favorite pattern : the domain pattern. I feel that this pattern will allow developers to quickly and easily extend the source code to add all the goodies specific to their organization. Adding a new class of business object is as simple as 1, 2, 3:
- Create the business object (pattern, you can copy and paste an existing object and just edit the properties)
- Create the Data Access Class (pattern, once again, copy and paste an existing DAO class and modify the sql to suit your needs)
- Add the data access class to the domain manager's supported classes list.
Voila! You have a new object all ready to go and be used in the application. I can literally have a new business object built and hooked up to the database in 10-15 minutes. My domain pattern has evolved, I'll be reposting it someday soon, but here is an older model for those that are curious.
So that's what I've been working on when I'm not working the day job, doing my MBA homework, or spending time with my wife who has been very patient with me. I hope to have an evaluation version available in the next 60 days and I'm working damn hard to be sure that any developers who get their hands on the sourcecode (can be purchased as an add-on) will be able to learn the domain pattern and find their way around the application easily.