One of the roles I’d like ALT.NET fulfill within the greater .Net community is to be a second pole of leadership and thought. I say a “second” pole, because the .Net community already has a long standing traditional leadership -- the book authors, the MVP’s*, the INETA speakers, and whatnot. They’ve done plenty of good in regards to explaining how to best use existing and forthcoming Microsoft tools, but I think there are a lot of valuable subjects and viewpoints that are largely missing from the mainstream .Net dialogue. Specifically, I’d like to see ALT.NET start to fill what I see as a void for information and leadership on:
- OOP fundamentals. I think we as a community would achieve far more benefits on our projects from a stronger base of OOP design knowledge than we do for learning new API’s like WCF or LINQ. Learning the fundamentals will make us far better able to choose and use these new API’s.
- Development processes and practices. Microsoft builds and sells tools, and they naturally see tools as the solution to most problems. We the community should be completely in charge of determining our best practices because we are the ones out there building software. Go to a .Net centric development conference. Outside of some token Agile track, you will not see very much about configuration management, project management, requirements, testing, or the all important people issues. A lot of Linq to XYZ talks, but not much about running successful software projects.
- Alternative tools. Some of the tools Microsoft makes are great, but some are inferior to non-Microsoft options. Some of these alternative tools open up entirely new possibilities in how we can work. I’d like to see the entire .Net community to simply broaden its horizons to be more accepting of tools originating from outside of Redmond.
Two recent podcast's illustrate to me why I think something like ALT.NET has some value to offer the community by filling holes in the dialogue. First up was Lerman on the Entity Framework on DotNetRocks. I promised Julie that I wouldn’t burn her in effigy here, so I’ll just say that I think that podcast covered the Entity Framework from a very data centric viewpoint that skated over some important concerns about using any persistence framework. Namely, what does this tool do to my business layer and the application as a whole? How much does the tool intrude on the rest of the application? From my own, very different viewpoint, the Entity Framework is conceptually flawed in some significant ways and won't let me work in the way that *I* think makes me the most successful:
- In my opinion the new “conceptual model” in the Entity Framework that allows you to treat the database more as a set of hierarchical entities is a poor substitute for fullblown OOP programming. I think the conceptual model is unnecessary complexity that detracts from the usability of the EF.
- The lack of transparent “lazy loading” in the Entity Framework is a dealbreaker for me. The need to explicitly say “Order.LineItems.Load()” makes the EF a very poor fit for Test Driven Development by making the EF objects difficult or nearly impossible to use independently of the database. Lazy loading should be completely transparent to the business logic, and I should be able to completely express the business logic without letting infrastructure concerns leak in (that Separation of Concerns thing). The podcast completely whiffed on this topic in the discussion of “POCO” objects at the end of the episode.
- At this point, EF couples you very tightly to the database. Support is very weak at this point for Domain Driven Design techniques. I really don’t think the EF is usable without using codegen to bake in the change tracking code that EF wants to be in the objects. Codegen-ing your business objects pretty well eliminates evolutionary design or keeping your domain logic in these classes. I know you can use partial classes for the business logic, but that's sooooo clumsy. Besides, the codegen is more or less optimized for scenarios where you merely replicate the structure of the database in the object model.
Many people don’t feel that the EF picture is all that rosy, but those concerns simply aren’t getting much attention or understanding from our traditional community leadership.
The second podcast was .Net author Rocky Lhotka being interviewed on Hanselminutes about data access issues. I mostly agree with Rocky on the general goals, but I think there's better mechanical ways to achieve an effective object model strategy than what Rocky was espousing on the show. Rocky gets some serious points from me for talking about Responsibility Driven Design (my choice for the single most effective design technique) and the Single Responsibility Principle (SRP). Ironically enough though, I advise people against using his CSLA.Net framework in no small measure because I think CSLA violates the Single Responsibility Principle.** It may be that Rocky and I have vastly different interpretations of the SRP, but that again points to the validity of a second pole of thought and discussion because I really don't think that Rocky (or any one else including me) gets to be the sole voice who gets to define design best practices.
One of the other things Rocky said was that ORM tools tightly bind your object model to the database. His suggestion was to use an ORM as just a data access layer and manually write mapping code within your business objects to translate between the database model persisted by the ORM and your own domain model classes. I thought this was terrible advice in most situations because it's unnecessary, and putting that mapping code inside your business objects let’s infrastructure concerns bleed into my your domain logic code (a clear SRP violation). When I use NHibernate, I can write my business objects in a structure that fits the behavior of the business logic the way Rocky and I both want to, but I can also persist these objects to a database structure that makes sense for the database with very little impact on the business objects. I do not have any need to write all of that tedious mapping object-to-object code that Rocky was suggesting. I don't know if Rocky was purposely overlooking the capabilities of NHibernate or the WilsonORMapper in favor of his traditional CSLA approach, doesn't believe in ORM, or if he just flat out doesn't know. Either way, we need some alternative sources of information, and dare I say it, visible authority figures in the community.
Sometimes the Microsoft solution isn’t the best
Both podcast's were lacking in well informed opinions about alternatives to the Microsoft tooling on data access, and I think that's probably my biggest reason for writing this post. If my choice was really a binary decision between Linq to SQL or Linq to Entities and rolling naked ADO.Net code, heck yes I'd jump for joy about the EF. Fortunately for us, that's not the case.
The biggest problem for me with the EF is that I think there are simply better existing tools for the vast majority of projects. For simpler CRUD or reporting applications, SubSonic is basically the exact same kind of “generate strongly typed object wrappers around the database tables” solution as the EF and Linq to SQL, but I bet SubSonic would be much easier to use. LLBLGen Pro is much more feature rich than the Entity Framework. NHibernate is vastly better if you want to use a rich Domain Model approach for your design and/or want to most effectively utilize TDD. iBatis.Net will probably be easier to use for nastier legacy database schemas and give you ultimate control over the SQL with lighter weight mapping than the EF. Heck, LLBLGen Pro and NHibernate are well on their way to having full LINQ support, and SubSonic has a strongly typed query language, so shoot down that advantage for EF. My preference is NHibernate, but I was very happy with my usage of the Java version of iBatis.
I honestly believe that if we don’t have any useful alternative to the traditional .Net leadership, all of these arguably superior tools will be shoved to the sideline in favor of the deeply flawed Entity Framework. Worse yet is that we might not get better tools because I don’t think our traditional leadership does a very good job of giving useful feedback to Microsoft to help make these tools better. I really do believe that our traditional leadership largely sees new tooling as simply opportunities to write articles, books, and be visible conference speakers rather than something that needs to be carefully evaluated and possibly rejected. I want leadership that can help us make good judgements about how and with what we should build software instead of just relaying the guidance from our toolmaker.
Summing Up
I didn't say here that I think we need to completely swap out our entire leadership clique. All I want is an additional set of leadership types who are discussing other points of view to give us a more rounded conversation. To some degree, I think we might just need a new generation of leadership that didn't come up through Windows DNA programming. Lastly, I don’t really care if it’s the ALT.NET movement specifically that starts to fill this void as long as it’s filled by somebody in a useful way.
When some .Net poobah says that every class should be accessed through WCF, someone else should speak up and say "that's insanely stupid," but in a reasoned, adult like manner. And if any MVP speaker type says you should be using the Entity Framework/WF/putting all your business logic into XAML/whatever, I want to see some dissenting opinions too.
Comments are open. Feel free to disagree with me.
*To be fair, many of the most visible ALT.NET members, including myself and many other CodeBetter bloggers, are also MVP’s of one sort of another. I’d still say that we make up a very small minority of the total MVP lineup.
** To the CSLA proponents out there, I’m going to issue you a challenge. Run static code analysis numbers on your CSLA “business” objects. I’ll betcha that the Cyclomatic Complexity numbers are uncomfortably far into the dangerous zone – and yes, if this is so, this is something you should be concerned about.