DevPinoy.org
A Filipino Developers Community
   
POCO (Plain Old CLR Objects)
Has this "philosophy" or approach in .NET development caught the attention of many yet?

POCO of course is the .NET version of POJO (Plain Old Java Objects), which is the approach of designing Java business objects that do not depend on some container or environment like the monstrous EJB.

I've been practicing this approach lately...no ADO.NET in business objects, no external dependencies, no ConfigurationManager or ConfigurationSettings.AppSettings stuff. Every dependency should be injected via the constructor (or the appropriate method call) and there is heavy reliance on interfaces. This way I can choose to inject any implementation of those interfaces, with various implementations doing either database access or mock functionality. (A while back I was starting to become a fan of the CSLA.NET framework, but lately I'm getting the impression that using it results in non-unit testable code. So now my preference has changed.)

And I like it. My output is lightweight, testable and predictable. My ASP.NET code behind (since I do web apps practically all the time) feels like I'm just wiring objects up.

What's your take on this concept?

Posted 09-01-2006 2:27 PM by cruizer
Filed under: ,

Comments

TuldokLambat wrote re: POCO (Plain Old CLR Objects)
on 09-02-2006 10:03 AM

"no ADO.NET in business objects"

How do you data access then?

smash wrote re: POCO (Plain Old CLR Objects)
on 09-02-2006 10:38 AM

cruizer probably meant no ado.net in his "domain classes".  a classic example of the opposite would be WEO as promoted by an enterprise architecture book from Wrox.  

cruizer wrote re: POCO (Plain Old CLR Objects)
on 09-02-2006 4:43 PM

you're right smash. i don't put ADO.NET references in my domain classes. but of course there's a data access layer that the domain classes can use, and those are the ones that will contain data access code (whether by using XML, using ADO.NET or web services)

Copyright DevPinoy 2005-2008