I touched on this last year sometime, but I was frustrated at the time and might not have made much sense. I’d like to try again to see if I can get some constructive advice.
I am having an issue in choosing a persistence engine.
My first choice is FluentNHibernate / NHibernate. However, I am having severe difficulties with their criterion and projection mechanisms. Searching for examples is difficult and when I do find something, I really don’t understand what I’m looking at. After a year of trying to bring this together, it still eludes me. I know I could just ask here for help with certain things, but you guys have more things to do than sit and teach me nhibernate criterion.
My second choice is Entity Framework 4. I am leaving the CTP 5 off the list for now as there is a major bug in how self-referencing tables are handled at the moment. Now, I have two sub-choices here. The first involves using code first by turning off code generation in the designer and place my enities and edmx in separate libraries (.Domain and .Persistence.Mapping) but this involves a bit of extra work. Then again, for simplicities sake, I could just dump the edmx designer right in the domain library. But this means having the mapping info in the domain library. Not ideal, but it’d work.
Please note that with EF, I still retain the ability to map collections, references and properties as protected or private, and add logic-checking accessors to the entities, as well as setting a protected and public constructor. The entities would still be strong, valid business entities.
With these points in mind, what direction should I head?
You know, choose what you like the most. Both are used. I, for one, am using Ado.Net directly (with a dash of linq2sql if I’m too lazy) since is the easiest way for me.
I don’t think there is a perfect solution, so take the easy road.
I like your thinking here and took your advice. For this project, I chose to simply use the EF desginer in the domain project. The only real impact is that the mapping info now resides in the domain project rather than the persistence project. I can live with this.
What major bug are you talking about ? I am currently trying to find a way to use EF4 CTP 5 with patterns… and got a strange bug. EF4 create the table but doesnt lets me insert data. Also the database object connection state is set to false and it seem that serverVersion is throwing an exception. I can’t figure out why. I believe that unrelated?
This is the correct way to map this relationship, but since it is self-referencing entity instead of two different entities, it causes the error “Sequence has more than one matching element.”
This has been reported several times aparently. At least that’s the word I got back from them.
Alright. Yeah i saw the error being reported to microsoft in their community area. It seem there was a workaround. This will surely be fixed soon.
Anyway i found solution to my problem. About your problem… i am not even using EntityTypeConfiguration… Ive heard we could use OnModelCreated to refine the mapping between the entities but ive never heard of EntityTypeConfiguration. Where do you define that ?
public class DomainContext : DbContext
{
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Configurations.Add(new AuthorClassMap());
modelBuilder.Configurations.Add(new BookClassMap());
modelBuilder.Conventions.Add(new TableNameConvention());
}
}
Of course, you can always use reflection and add these automatically. Really it’s just a way to isolate your mappings and conventions instead of lumping it all in the context.
It’s exactly like using the fluent mapping directly in OnModelCreating. The only difference is that we now move the mappings to entity specific mapping classes, and then use OnModelCreating to include them.
Ah, alright i understand now. Thanks for the explanation. I am rather new to this and mvc developement and i hope to get further knowledge in the area.
With your specific requirements, why not forgo the ORM and just write stuff in straight SQL? I don’t think one can find any ORM that won’t require a compromise somewhere which seems to be out of the cards for your project.
web, I took a while responding to your suggestion because it’s something I had actually considered. But I wanted to take some time and really think about it.
The first thing this suggestion did was remind me of my PHP days. Back then, I was a novice at advanced programming and probably would have done this very thing. What we know as the domain layer would’ve merely been simple property classes that represented actual table fields, with no relational-navigational properties. With such a design, this could hardly be called a domain. None-the-less, it was simple and it worked. The only real change in controller action code would be a nested call to a repository and extra foreach loops to gather related data and map them to the view models. The on-screen result would be the same.
Completely eliminating the ORM element actually seems like a good idea at present, despite me having put a great deal of time into learning them.
I’ll play around with it a bit in this toy project I have and let you know how things turn out.