Background

I really like Fluent NHibernate - it's pretty great. I don't have to write those mundane CRUD-based SQL stored procedures and that's great 开发者_如何学Python(not that there's anything wrong with that)!

I've gone down this path a bit on an application we're working on. And now I'm sitting with a couple dozen domain objects, each with a repository interface and corresponding concrete repository. Whew!

But wait - did that really save me all that much time? It felt like it took more time. I had to write all these domain objects which are 99% properties and 1% business logic, then I had to define the mappings. That takes about as much time as writing a stored procedure. So what benefit does using Fluent NHibernate provide me over just writing stored procedures?

Question

Are there any reliable solutions out there for generating those "property bag" domain objects (in .NET) so I don't have to write them? I could see some benefit in that, so long as the objects provided for some extensibility to add extra business logic as needed.

---

You can generate the mapping with Auto mapping. NHibernate is ideal for greenfield applications, most people using NHibernate write their domain objects and generate the database from it. You like to do the opposite, you have an existing db and want to generate the domain objects. There is no solution in NHiberante for that, but you can write a small script using MyGeneration, CodeSmith or some similar code generation tool.

---

May be you should think the other way round. While developing you could generate your SQL-Schema from your objects (FluentNhibernate supports this). That way you can develop your domain model in an iterative process, with probably many changes along the way. The data model could be just an appendix.

Writing objects is from my point of view is as easy as creating tables and adding fields in your schema management tool. In fact i believe writing business/domain object is faster :-)

If you have an anemic domain model, it is probably because your application is young. More functionality will come :-)

---

Instead of separate repository interfaces and concrete repository classes for each aggregate root, try creating a single generic repository interface and concrete implementation.

If you need to add some specific functionality for one particular type of entity, well, extension methods can help you out there.

Have a look at this example from Seb Lambla: http://serialseb.blogspot.com/2009/08/nhibernate-repository-that-oren-wont.html