This project is read-only.

nHydrate and MVC: significant design conflict

Feb 11, 2012 at 3:08 AM

Can the nHydrate code generator be modified to not use the MetadataType attribute to "add" metadata to the fields of an entity class file? A quick glance at a few generated metadata classes makes me think this could be done as I don't see anything in the metadata classes which looks unusual. I'm not privy to the architectural decisions behind why nHydrate does things this way, of course.

The reason for the request is simple: the current approach, with separate metadata classes, effectively makes nHydrate impractical for use in ASPNET MVC applications. That's because MVC relies heavily on declarative/attribute-based programming to define the UI. The entity classes defined in nHydrate are a natural fit for MVC model files, making it important to be able to include the MVC-based attributes in the entity definitions.

The only alternative to this that I can think of requires creating proxy classes for any nHydrate entity that you wanted to use as an MVC model file. That would quickly become tedious. It also presents significant maintenance issues, having to keep two separate data structures in sync, and it requires a lot of assignment operations to move values between nHydrate entities and MVC model classes. Basically, it's a big pain for anything but the most trivial MVC applications.

MVC allows attributes to be derived from a buddy class via the MetadataType attribute. That's done so that you don't have to hack generated entity class files to add the attributes. Which would have to be done after every schema generation. But only one such attribute is allowed per class. In other words, nHydrate's usage of the MetadataType attribute conflicts with MVC's usage.

Bottom-line, unless there's another workaround, I can't see anyone using nHydrate for a real-world MVC project. Which would be a shame.

- Mark