Monthly Archives: December 2012

Date Night Planner

Date Night Planner

Date Night Planner

Date Night Planner
Need help deciding what to do on your next date? Date Night Planner randomly selects from lists of activities and restaurants that you enter to create an itinerary for the evening. The lists are fully customizable so be creative and have fun!


Notes on Date Night Planner coming soon

Date Night Planner

DateNightPlanner-Screenshot-2

DateNightPlanner-Screenshot-3

Screenshots


Support

Support coming soon…

Mayan Calendar Ends Today

The Mayan Calendar ending today kind of reminds me of Y2K.  Not because of the “end of the world as we know it” implications, but because it was a tool that when constructed, allocated enough room to work for the foreseeable future.  The two digit year stored in databases throughout the 20th century worked just fine for the inventors just as the Mayan Calendar did.

So on this auspicious occasion I’ve decided to completely redesign Climers.com; which will act as a portal for my other projects such as my blog, and my web comics site.  I think this will work just fine…. for the foreseeable future.

Mayan Calendar

Mayan Calendar

A simple definition and example of a POCO object in .NET

It shouldn’t be so difficult to find an article on POCO that actually explains what it is and gives an example. So to make the world a better place, here ya go:

(From Wikipedia)
Plain Old CLR Object or POCO is a play on the term POJO, from the Java EE programming world, and is used by developers targeting the Common Language Runtime of the .NET Framework.

Similar to the Java context, the term is used to contrast a simple object with one that is designed to be used with a complicated, special object frameworks such as an ORM component. Another way to put it is that POCOs are objects unencumbered with inheritance or attributes needed for specific frameworks.

So what does this mean?

A POCO object is one that doesn’t rely on a framework to exist. For example, a WebForm object relies on the Web.UI.Page object which relies on an entire ASP.NET framework and therefore is not a POCO object.

What different does this make?

Well, if I’m writing a WCF Service that I want to return an object, it wouldn’t do much good to return an object that relies on a framework (or contains abstract methods or properties that point to nothing outside of the original environment) that the consumer may not have access to. But, if I create a simple object, such as one that contains mostly properties and a little business logic, I can easily return this from a WCF Service and use it in pretty much any application I want (Web, Desktop, Windows Service, Silverlight, other WCF services, …).

This is my understanding and I welcome further input.