Something is going on out there…
While I still work on LINQ 2 SQL some people started an open discussion, rant, or rail (depending on one’s view and taken offense) about the upcoming Entity Framework.
In all frankness, an “ADO .NET Entity Framework Vote of No Confidence” (VoNC from now on, see here) is certainly capable to triggering off some very strong reactions.
What I disagree with is the way in which it’s presented. The language of “Vote of No Confidence” is intended to start a fight and is long hand for “You suck”. […]
I’m not upset that people are giving feedback. I want them to give feedback. But here’s the deal – do it in a grown up way. My way or the highway doesn’t sit well with anyone on the receiving end. There’s a WIDE path between being constructively critical and downright offensive.
(Josh Holmes, Ranting and Raving or Getting Results?)
Also quite funny: While the VoNC has probably been popularized by Mary-Jo Foley, she instantly got her … feedback …. from one of the VoNC’s authors:
The signatories list represents leading developers, architects, and practice leads within the Microsoft community. The representation of the signatories as testers is misleading and inaccurate.
We would appreciate an immediate retraction and correction of this misrepresentation.
(Scott Bellware, MVP, see here)
Seems people got a little testy. Anyway, Scott also points out “the history of the feedback and relationship between the community of experts and the Entity Framework team going back to April of 2007”, which raises the question why they still had to publish the VoNC in the first place, despite that relationship.
Given all that, Microsoft’s response was a fine example of “cooling things down” and trying to focus in the facts. Well, essentially Tim more or less tells us that all the VoNC asked for will be kind of there in EF v2.
But already the VoNC is experiencing string headwind. Most is aimed at the, well, call it appearance, of the VoNC and a nice listing can be found here. There is even an “An Open Letter to the ALT.NET Community” (see here).
My opinion?
Thought I would spare you? Silly you 😉
What instantly caught my attention, if just because it was the first point made in the VoNC, was the statement that “entities are more significantly behavioral objects from the perspective of entity-oriented applications” and the claim that this is a “key architectural enabler and distinction”.
Having some experience with EJB those statements vividly reminded me of entity beans. I have expressed my opinion on the notion of “intelligent data objects” (for lack of a better term) more than half a decade ago:
My opinion is that the support of statefull components (i.e. entity beans) in J2EE is one of its biggest weaknesses. Not because it’s technically bad but it leads to wrong architectural design decisions […]
(microsoft.public.dotnet.general, 4/9/2001, see here)
The reasons for this opinion in 2001 (scalability, reliability, etc.) are still valid. Additionally there are a bunch of other reasons: Trends to lightweight architectures have prospered in Java and even affected .NET (back then, DataSets were the means of choice, today entity classes are very common). The Service notion put emphasis on data shape and operations on that data. Business process engines move data from system to system, shaping and reshaping it along the way. In the distributed, sometimes disconnected world that our enterprise environments have become I could build cases against behavioral objects around security, maintenance, outsourcing scenarios, versioning, testing (which is ironically so favored in the VoNC), software complexity, future safety, and so on.
The VoNC seems to imply that if you don’t have “behavioral objects from the perspective of entity-oriented applications”, then you are stuck with “data objects from the perspective of data storage and data storage technologies” (as I read it more or less simple mappings from database tables to objects). Well, correct me if I’m wrong, but data can be reshaped without putting behavior in it. That’s exactly what I expect from an ORM tool like EF.
I’ll stop before I get carried away. Much to my own relief, I’m not the only one having these reservations, though: Ian noted the similarity with EJB as well and got deeper in this topic. Ward makes a good point on the issues of “Persistence Ignorance” which I share and thus won’t reiterate here.
Where are we?
As I see it, the ongoing discussions are circling around the issue on whether entities should follow the data centric pattern of value objects, or whether they should be complemented with behavior to become business objects. That is largely a matter of taste.
On the other hand, the discussion is somewhat misleading. The topic has got nothing to do with domain models, which in itself is agnostic of those two approaches. And the VoNC’s reference to the anemic domain model (i.e. a domain model based on value objects) only muddies the water. The very verdict that this is an anti-pattern, and a horrific one at that, is due to a judgment by Martin Fowler and only justified by the fact that it violates OO principles (which is obvious) and people think (yes, they do, according to Martin) that value objects are real objects. No wonder the VoNC calls this a “degraded architecture”.
So, two opposing forces, standing in muddied water, and Microsoft caught between them. The PDC is going to be interesting… 😀
BTW: Please note that I never said, Microsoft should not do what the VoNC asks for. There are bright people among the signatories and they should not be ignored. Microsoft as tool vendor should provide a tool than can be used in any architecture.
That’s all for now folks,
AJ.NET
AJ's blog 
This is the first post on this whole thing that A.) I didn’t immediately make me go “WTF is the big deal” and B.) Educate me on the real issues being discussed (argued). I’m frankly tired of the whole thing myself, but you brought up some ideas I wanted to know more about.
On to the whole value objects (Are you talking DTOs basically?) versus business objects. In the value object architecture, where do you prefer to place the behavior? Service objects?
My team went the route of DTOs for about 2 years with business objects containing the behavior and the data reformatted into the desired business object’s profile. We really hated the architectures we created using that model and the difficulty of maintinance (LOTS of change requests in our systems as the business processes are always evolving) when translating through all the layers, etc. We now use business objects with simple CTORs (Usually just dependency injection CTORs) and an Object Factory to create the object in the Data Access layer, set the appropriate properties and return it. I should note that these objects are Stateful based on their data, though the state is computed with every behavior execution and use of a property that’s state based. Hopefully that makes sense.
For the most part we’ve found that we usually end up with a 1-1 mapping of DB to business objects in our applications regardless of the architecture so it made sense to just embrace that and get rid of the extra work of DTOs, testing DTOs, and updating DTOs.
Comment by Lucas Goodwin — July 24, 2008 @ 3:55 am
@Lucas: First, thanks for the good feedback 🙂
Regarding your questions: Yes, DTO and VO are interchangeable terms (see http://en.wikipedia.org/wiki/Data_Transfer_Object). Basically a really dumb object, consisting only of properties and perhaps some attributes for meta information (as opposed to BOs with data and behaviour http://en.wikipedia.org/wiki/Business_object_%28computer_science%29 ). Within a typical application some kind of Data Access Layer (e.g. an ORM) produces DTOs, that in turn “flow accross the layers” to the presentation and back, being reshaped and manipulated along the way. So to speak.
Your question “where do you prefer to place the behavior?” actually aims at the heart of the issue why I prefer DTOs over BOs (i.e. data + behaviour). My answer is: I put it where it belongs – and it does _not_ belong in one place. IMO behaviour is context dependent. To be more concrete let me quote an earlier post:
“[…] So let’s put the Validate() method (used by the business logic) into the entity, the FormatForPrinting() Method (used by the UI), the GenerateUniqueId() Method (used by the data access layer), … damn, that format method produced HTML but this client needs XAML… . And is this IsReadOnly() method for the UI or the data access layer?
Got the idea? There is reason not to put those methods into the entity class: they do not only depend on the entity but also belong to their specific context, in this case a certain layer.”
So, in the business layer I have a business component working on an entity, in the data access layer I have a data access component also working on it, but doing different things. This favours http://en.wikipedia.org/wiki/Separation_of_concerns which is one of my favourite paradigms.
If I understand you correctly, then we think in the same direction, I’m just not sure whether you are already there. “My team went the route of DTOs […] with business objects” seems to be a contradiction. It’s either DTOs (i.e. dumb data containers) or BOs (i.e. data and business behavior). “We now use business objects …” seems to me like having BOs but using them as DTOs. This is a mixture of two contradictory approaches, which I don’t like very much.
I also don’t quite follow you with the “extra work of DTOs”. Testing is not an issue (no functionality to test) and quite often code generation mechanisms (LINQ 2 SQL, service proxies, … ) will even do some of the work for you.
HIH,
AJ.NET
Comment by ajdotnet — July 24, 2008 @ 8:40 am
@AJ
Thanks for the quick response. The “DTOs with Business Objects” is a contradiction and I realized that when I reread it. Probably why we had such issues. Basically we would use a DTO between two layers, but not all the way through.
I went over what you said with some of our team and I think we get it now. Instead of “Business Objects” we really needed things like service objects, workflow objects, repositories, and validators. Breaking up the business layer into smaller distinct behavior objects with each of those only having one concern, be that coordinating a workflow (And the other services) or performing a DB lookup.
Basically we were combining service coordination (workflow) with all the other behaviors into large entities in the business layer that forced a good deal of dependencies and made it very difficult to modify without breaking a whole lot of other things.
I’ve been trying to get our architectures to where the presentation layer for a particular client coordinates things as it’s interface sees fit, but we always found ourselves locked in on the presentation layer due to the business layer.
I see the light, I think. We were 3/4 of the way there already.
The other advantage I see in going with a DTO/Services architecture is that adding in a service bus or creating a web-service front end into the business layer becomes a fairly trivial thing. With our entities, not so.
Btw, it seems to me that with ORMs (LINQ, Code Gen, NHibernate) you really need to already be familiar and comfortable with the architectures they were designed to support before you can adopt them. With that in mind, it strikes me that LINQ is just targetting a different set of architectures then NHibernate, and a lot of the Domain Driven Design guys don’t like that architecture as much.
From my perspective, I actually think LINQ 2 SQL is worth atleast investigating. It’s LINQ to Objects that I really question. The idea of embedding query like language syntax into all my layers doesn’t sit well. Then again, I hate SQL. I do see the value of both products however and reserve judgement until I actually use ’em (which I haven’t).
Comment by Lucas Goodwin — July 25, 2008 @ 2:23 am
Oh, I forgot to add. The “Extra work of DTOs” is because we don’t use ORM solutions at the moment so we code the DTOs by hand. By then using BOs in the business layer that meant a good deal of duplication by replicating the same DTO interface in the BO. Anotherwords, like I said before, we were turning dumb objects into smart objects.
The lack of ORM is mostly a result of the team really not having a solid foundation of OOP concepts. Most of my team has been doing Classic ASP for 10+ years and only moved to .NET 3 years ago. In addition I’m an old C++ guy so even my concepts of OOP were rather out-dated.
As such, we’ve been focusing on getting everyone on the same page before throwing even more tooling into our processes. Already instituted TDD concepts and Inversion of Control containers, but it took a year of building systems with the poorman’s IoC before everyone was comfortable enough with the concepts to appreciate and use an IoC container.
Comment by Lucas Goodwin — July 25, 2008 @ 2:34 am
@Lucas: I’m glad I could help.
Regarding your LINQ 2 Objects reservations: Actually I have more reservations about LINQ 2 SQL (still counting the deficiencies and working on respective blog posts). I found that LINQ 2 Objects really cuts down the amount of code to write when working with collections. Have a look at https://ajdotnet.wordpress.com/2008/04/13/linq-to-objects-reality-check/ as a teaser. Also I would like to encourage you to look behind “The idea of embedding query like language syntax” in your code. This is really just the tip of the iceberg (a big tip, no doubt). https://ajdotnet.wordpress.com/2008/04/27/i-cant-help-but-notice/ may give you some ideas.
But I agree that functional programming (even if limited to LINQ 2 XY) introduces some new ideas that have a learning curve in code as well as in architecture. And it’s really sensible to take one step at a time. Still, have a closer look at LINQ 2 SQL. Its code generation features may help you quite a bit and there’s enough information in the blogsphere about how to use it in a web application scenario (including mine in the near future 😉 ).
AJ.NET
Comment by ajdotnet — July 25, 2008 @ 7:42 am