http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660> (persistence ignorance) is important because we don't have mixins in .Net Since I learned bout the extension methods in .Net 3.5 I've been playing with the notion of an "ActiveRecord mixin". Granted it's not exactly the same thing and would still have limitations. I'm curious to know if anyone else has any thoughts on that. I mean, implementing some of the AR instance methods as extension methods and freeing your object's inheritance decision (maybe requiring one marker interface.) One drawback I saw is the need to import the mixin namespace whenever you need persistence code. http://ayende.com/2235/plain-old-net-classes#comment4http://ayende.com/2235/plain-old-net-classes#comment4Tue, 20 Mar 2007 12:45:35 GMT> utilize the .NET framework in full Can you define what you mean not utilize the .Net framework in full? You mention data binding, XML serialization, etc. All of them require non trivial work on the side of the class in question, I agree, and that get fairly annoying very fast. I don't have a problem with POCO being anemic, it simply means that it has no business logic associated with it. Usually it is meant mostly for display / reference. As I mentioned, POCO is not always the easiest solution, Active Record handles a lot of the stuff that NHibernate does for me, and base classes such as Rocky's CSLA framework handle data binding, undo, etc. Also, am I the only one who literally had given up on two way databinding ? The amount of stuff you have to do to get it right is simply too big. I write custom code for this, and it is much simpler to use and work with. http://ayende.com/2235/plain-old-net-classes#comment3http://ayende.com/2235/plain-old-net-classes#comment3Tue, 20 Mar 2007 10:35:12 GMT"If a POCO is 60% plumbing, it is not a POCO, period." Though, doesn't that mean that poco classes can be really aenemic? (Which according to some people is an anti pattern, because mr. Fowler said so). I agree that it would be better to have no plumbing in a class, though in some occasions you can't avoid it, basicly because the .NET framework wants you to implement given interfaces so the object can be used with .NET framework functionality. So you then have a choice: 1) write controllers for most parts of your application, so you can avoid plumbing in your classes, though this comes down to re-doing a lot of the functionality already available to you via the .NET framework 2) utilize the .NET framework in full and add plumbing to your classes. Both have downsides and advantages. I'm not so sure point 2) is that bad, as in most cases the domain objects aren't re-used in another application anyway, so the sole reason to go through all the work for point 1) is basicly 'because someone said it was better though we won't utilize the advantages in this project'. At least, that's what I have to conclude, as the # of times one will swap o/r mappers is rather small and most people won't do that at all, as doing so will cause problems anyway so doing all the work for 1) isn't making it less painfull. @Steve: I wasn't talking about db plumbing, I was talking about .NET framework plumbing, like databinding crap, XML serialization code etc. Especially code for databinding is a true pain if you want to do it correctly. http://ayende.com/2235/plain-old-net-classes#comment2http://ayende.com/2235/plain-old-net-classes#comment2Tue, 20 Mar 2007 10:01:01 GMTThis is one of the reasons I'm prefering NHibernate right now - all the mappings are done outside of my objects. Layering applications is important for many reasons, and if you put your database plumbing in your POCO classes, you are going to make it difficult to make changes down the road. http://ayende.com/2235/plain-old-net-classes#comment1http://ayende.com/2235/plain-old-net-classes#comment1Tue, 20 Mar 2007 00:38:59 GMT