# 26 Haziran 2008 Perşembe
Kathleen Dollard wrote a response regarding the Vote of No Confidence on the Entity Framework. I was reading her post knowing that there will be lots of posts circling around the Vote of No Confidence, some will agree and some won't, and that was such a post from a particular point of view, until I hit this one (emphesis not mine):
"Entity approaches are good because they better separate the business and data sides of our middle tiers. But they are also inherently difficult and inaccessible to most programmers. Entity Framework’s goal must be to bridge this gap. That means being extremely creative in picking its battles to reach toward the real world developer – not copy a strategy that is available to that developer today and fails (the combination of NHibernate and other tools used in a specific style of development). The failure is not because NHibernate is an Open Source tool. It’s not because people don’t know about it. If it worked in the majority of shops it would burn through our industry like wildfire. Why don’t you use them? Because they do not fit your development environment!"
Sorry, but this is FUD or what? What's the ground here to say that NHibernate, or any O/RM approach mimicking it, is failing? Does Linq To SQL, which is no different in theory than NHibernate but lacks most of it's features, is a carrot from MS to the impatient while they wait for the uber EF framework? What makes something fail in MS land when it is actually quite successful in other platforms? Take TDD, for example. It works, appearently, and gaining some momentum. But it's nowhere near burning through our industry like wildfire. You can't make average Joe and his boss accept TDD as the defacto way of writing software. Does that mean TDD fails? Do we need some other über-TDD to replace it at the moment?

NHibernate does actually fit very well into my development environment, and I see no reason why it won't for any other developer. It has a clear SoC attitude, minimalistic configuration (compare NH xml configuration files with any behind-the-scene xml dialect from MS and you'll know what I mean), nice performance. It has everything if you want to write maintainable code. That does not mean that it's irreplaceable, but it just works, now, and any newcomer should challange it, not vice versa.

But yes, it does not fit the development environment often thought by Microsoft. Last year, I have paid a visit to a client who was suffering lots of performance, scalability and mainly maintainability problems with their in-house written ERP system. It turns out that, the application was built on typed datasets start to finish. They decided that they need to port their application to .Net, took some courses along with MOC 2541 (part of the official MS curriculum saying that data access is a solved problem if you use drag'n drop and datasets), realized that typed datasets is the ultimate-easy way do access data and the rest is history for them. Don't get me wrong, I instructed almost all the courses in the official MS curriculum, but in each case I mentioned and demoed alternatives and told the audience that what they see in the official book is just part of the story.

In the last couple years I'm feeling much better about Microsoft, the direction they're heading, the way they're interacting with and listening to the community. I'm also a firm believer in code generation when it's due, wrote some tools to make developers' life easier (including people using NHibernate), and actually paid a visit to Cambidge, UK to meet the nice people of the DSL Tools team for a job interview a couple of months ago (I failed, appearently). I'm buying the toy my son wanted by spending the money I earned by using Microsoft technologies, and I'm happy with what I do. But I can't stand the "MS way or nothing else" attitude.

Microsoft is famous for handling developers as babies sometimes. If you're a C# developer, create a VB.NET project and you'll see that behavior precisely. In a VB.Net project, why project references or .designer.cs files are hidden? Where all this namespace thing gone? Where's the damn entry point of this application? The broad, ignorant world of MS developer echosystem (of which I'm a part of) is actualy ignorant because of this simple fact. In the past, we are always told that there's a specific way of writing applications, and you can find tools and documentation from Microsoft if you want to know what it is. If there's a problem already solved, it's solved by Microsoft. It's comfortable to leave the thinking to someone else and do what you told.

But times are changing, DAL == DAAB no more, we are more open and influenced by other tools, platforms and thinking. This is also true for O/RM tools / frameworks. I visit lots of clients every week, and O/RM is really something people are researching or already using somehow, be it in-house, EF, Linq to SQL, LLBLGen, NHibernate, or something else. So, again, how can one say that NHibernate is done, kaput, arrivederci? It's all just started, and minds are shifting.

In the long-run, reaching real world developers only works if you solve their real world problems with long-lasting frameworks. And by long-lasting, I mean frameworks that survive rewrites, gives you the opportunity to say that "I was right by selecting this" three years after your first deployment. I'm not saying that EF is not one of them, but we have seen many palliative solutions from MS that didn't last long, and the items in that Vote of No Confidence document are real and learned by experience. Real world experience.

posted on 26 Haziran 2008 Perşembe 08:49:33 UTC  #   
# 14 Haziran 2007 Perşembe

This was sitting on the trunk for a while because of a bug in NHibernate config generation. I believe it's fixed now, so let's see if it works :)

First of all, this release is trying to be compatible with Castle trunk, it may generate code usable by released Castle components but it follows recent changes (might miss a few days). You know, Castle will be 1.0 one day and ActiveWriter will be a release, not a preview, in that day.

And I'm trying create some documentation on using.castleproject.org (Castle's wiki) to make Hammett stop whining about the lack of documentation of contrib projects (kidding!). If you're using ActiveWriter and want to share your tips, tricks, workarounds or anything about it, it would be great if you contribute to the documentation.

The most important update is the direct NHibernate configuration support. Now you can instruct ActiveWriter to generate NHibernate configuration files (.hbm.xml) for each entity in your model. Generated classes won't have ActiveRecord attributes in this case. More on this in a later post (Update: here).



Another interesting change is the use of Castle.Components.Validator instead of the ActiveRecord validators. AR changed in the trunk to use it, so does ActiveWriter.



One more exiciting news is, you can drag tables of MySQL from Server Explorer onto the modelin surface (see Michael's patch below).

Full list of changes below. A big thanks to all who sent patches, ideas and bug reports.

New:
  • Now optionally generates NHibernate hbm.xml files.
  • Namespace in generated code is now customizable (Idea: Robert van Hoornaar)
  • Imports in generated code is now customizable (Idea: Robert van Hoornaar)
  • Model classes can override model level base class definition. (Patch: Robert van Hoornaar)
  • Model classes can override model level generics generation. (Idea: Robert van Hoornaar)
  • Contrib-26: Add support for AR Nested / NH Component mappings. Allow the ability to specify a column prefix for active record. (thx: Adam Tybor)
  • Optionally generates classes implementing INotifyPropertyChanged.
  • Support for drag-drop from Server Explorer for MySQL databases. Requires MySQL Connector/Net (5.1) (included). (Patch: Michael Morton)
  • Support for custom types through IUserType. See http://support.castleproject.org/browse/CONTRIB-28#action_11456 for usage. (Patch: Ricardo Stuven)
  • Ability to define a nested class with a different property name than the nested class (Idea: Craig Neuwirt)
Fixed:
  • Contrib-23: Produces CascadeEnum instead of ManyRelationCascadeEnum
  • Ability to generate virtual properties to support Lazy properly (thx: Ayende)
  • Make sure that Char and AnsiChar types are treated as a System.String types, instead of System.Char types (patch: Ayende)
  • HasAndbelongToMany does not take custom property names and not found behavior into account.
  • Can’t add a Many To Many relationship to 2 entities when the Class and Table names are different.
  • Column keys in many-to-one relations is not optional. (Patch: Robert van Hoornaar)
  • Partially fixing NHibernate code generation errors. Now works with a workaround.
  • Nullable types only when NotNull=false (Patch: Ricardo Stuven)
  • Changed to Castle.Components.Validator
And just one more thing. Someone asked me if ActiveWriter is a competitor for Linq to SQL. AW is just a servent of the heavyweight champion, NHibernate/AR combo. Linq to SQL is competing with NHibernate. I didn't have time to examine Linq to SQL designer, but it's built using DSL Tools just like ActiveWriter so some functionality should be alike. Other than that it's the framework, not the tools, important.
posted on 14 Haziran 2007 Perşembe 08:29:25 UTC  #   
# 09 Mayıs 2007 Çarşamba
Ayende, in his post on virtual entry barriers / learning curve of Castle pieces, said:
One of the main differences between OSS and Commercial software is the amount of time that is invested in the frills. Active Record and NHibernate has a designer, which is nice, but it is not a level 1 priority to any of the people using either Active Record or NHibernate. The reason is that both those frameworks were built knowing that a designer is not something that you should need in order to work with them.
That is, of course, super true for MonoRail and when I started working on ActiveWriter, I said "ActiveRecord is so simple, no one gonna use a code generator for it". Now I think somewhat different, in the context of O/RM designers.

When I think of working with ActiveRecord, I see it in two different parts. First is the sceleton of an entity; all the attributes tagging the class, properties and fields to describe the model to ActiveRecord and then NHibernate, eventually.

    [ActiveRecord()]

    public partial class Entity : ActiveRecordBase {

 

        private int _key;

 

        [PrimaryKey(PrimaryKeyType.Native, ColumnType="Int32")]

        public int Key {

            get {

                return this._key;

            }

            set {

                this._key = value;

            }

        }

    }


This code is a no brainer to write and AR has quite good documentation to get you there easily. But it's so repetative that it's the perfect place for using a designer. I don't say that people using ActiveRecord should forget all the attributes to define an entity alltogether, but once you studied the underlying workings of the framework I believe even the most basic framework can use a designer when it comes to the brute force part of the code. After all, you are designing some entitities and that's what a designer do best.

One problem here is that it's not easy to modify this kind of generated code. Thanks to 2.0, partial classes help great when adding new functionality, but it's impossible to modify generated getters and setters. DSL Tools is using the term "double derived" for the approach used to solve this problem, use an inherited empty entity instead of the original one around to make it possible to override properties. This model works fine in DSL Tools context but might make real world entities complicated. This one and solutions like this which makes code more bloated are, I believe, the dark side of code generating designers.

There is also the process of giving the entity some brains; validation, query helper etc. I, again, can see the value of a designer here. ActiveWriter can generate entities with ActiveRecord validators (and there's a JIRA entry waiting to port it to Castle validators). Thanks to his permission, I'll integrate Ayende's Generator into ActiveWriter to make it generate code with all the typed query functionality but ActiveWriter of course won't be writing the query.

The other part of working with ActiveRecord is knowing what the framework gives you, what does it do on behalf, what are the list of things to know beforehand to know before it starts persisting. You should know about lazy loading, order of saving, inverse relations etc. This is the point when you instruct the framework to manage what you designed before, and I think where a designer should keep it's hands off. ActiveWriter, and tools alike, should help developers to define metadata. They should not act like metadata manipulators to do the programming. I consider Ayende's comments above true in this part of the usage. A good O/RM designer should work without getting the way, and shouldn't make the user careless by doing the thinking on behalf.

posted on 09 Mayıs 2007 Çarşamba 14:42:35 UTC  #