Sort of prototyping.
Well, as I stated recently, I want to build a WPF version of the application I built for Veronica. But another thought is why stop at WPF? The XAML behind designing a WPF and Silverlight app is very close if not identical in some cases. This also means adding a new layer. I won't be able to use NHibernate directly in a Silverlight app due to the reduce version of .Net available which means a WCF service or some other such implementation added to the project as well.
When working with new technologies I typically like to make a prototype just to create a project that is small to begin with but does enough to prove that the frameworks I've chosen will work together to my ends. I'm thinking of doing something similar here before cluttering up my main solution with several new projects.
In University, it seemed that every time we learned a new language we did the same thing, a movie rating application. It is a small application to write, it required data storage, a UI and data manipulation. Hide all of the updates behind a WCF service and put the UI in both WPF and Silverlight and you have a project which is about as complex as the one I want to build.
Now, I'm gonna make a minor change to that. There has been something similar to a move rating engine that I've actually wanted to build for myself for a while and always stopped, a personal recipe application with reviews and ratings of the different recipes. This is a little more complex than the movie example because there is more than one thing going on, but it has the added bonus that I will actually use it when I'm done with it. Also, I think I'm going to post the source for this one freely on this blog as an example, since I was unable to find many good examples myself.
So, the new application I want to be able to do a few things:
- Create new recipes.
- Attach a review and rating to recipes.
- Modify a recipe, but retain both the new and the old. (Track revisions).
- Reason for tracking a revision, is that I want to have both recipes along with the reviews so I can track how a change in the recipe affected the outcome.
First task is to create the Domain objects. I will need the following at a minimum:
- Recipe - Represents the Top level abstraction of the recipe, contains the name, categories, etc...
- RecipeItem - Represents an ingredient. Contains the name, amount required, handling instructions, etc...
- RecipeStep - Represents an iterative step in the executing the recipe.
- Category - Represents the categories available. Instead of using a free form text field we will use an editable table.
- Review - Represents a review of a particular recipe along with a rating.
- Reviewer - Represents a person who is reviewing a recipe. In my case I will need one for Veronica and Myself at the least, but it is nice to be able to track who reviewed a dish as well. If I'm cooking for just myself I may be interested in only how I rated a dish as opposed to the overall rating.
So, off to build this...
Alex.
[edit] - Completed the first draft of the Domain objects I plan to use. The file can be found here.
, I have released it under the LGPL license, included in the root of the zip file:
http://docs.google.com/leaf?id=0B7jSfuxfxwTLNzVmNjJhODItY2E4ZS00OWU2LTg4YjQtZGNmMTY3Y2ZhYTU3&hl=en
When working with new technologies I typically like to make a prototype just to create a project that is small to begin with but does enough to prove that the frameworks I've chosen will work together to my ends. I'm thinking of doing something similar here before cluttering up my main solution with several new projects.
In University, it seemed that every time we learned a new language we did the same thing, a movie rating application. It is a small application to write, it required data storage, a UI and data manipulation. Hide all of the updates behind a WCF service and put the UI in both WPF and Silverlight and you have a project which is about as complex as the one I want to build.
Now, I'm gonna make a minor change to that. There has been something similar to a move rating engine that I've actually wanted to build for myself for a while and always stopped, a personal recipe application with reviews and ratings of the different recipes. This is a little more complex than the movie example because there is more than one thing going on, but it has the added bonus that I will actually use it when I'm done with it. Also, I think I'm going to post the source for this one freely on this blog as an example, since I was unable to find many good examples myself.
So, the new application I want to be able to do a few things:
- Create new recipes.
- Attach a review and rating to recipes.
- Modify a recipe, but retain both the new and the old. (Track revisions).
- Reason for tracking a revision, is that I want to have both recipes along with the reviews so I can track how a change in the recipe affected the outcome.
First task is to create the Domain objects. I will need the following at a minimum:
- Recipe - Represents the Top level abstraction of the recipe, contains the name, categories, etc...
- RecipeItem - Represents an ingredient. Contains the name, amount required, handling instructions, etc...
- RecipeStep - Represents an iterative step in the executing the recipe.
- Category - Represents the categories available. Instead of using a free form text field we will use an editable table.
- Review - Represents a review of a particular recipe along with a rating.
- Reviewer - Represents a person who is reviewing a recipe. In my case I will need one for Veronica and Myself at the least, but it is nice to be able to track who reviewed a dish as well. If I'm cooking for just myself I may be interested in only how I rated a dish as opposed to the overall rating.
So, off to build this...
Alex.
[edit] - Completed the first draft of the Domain objects I plan to use. The file can be found here.
, I have released it under the LGPL license, included in the root of the zip file:
http://docs.google.com/leaf?id=0B7jSfuxfxwTLNzVmNjJhODItY2E4ZS00OWU2LTg4YjQtZGNmMTY3Y2ZhYTU3&hl=en
Comments
Post a Comment