0

I just stumbled across an EF Code First tutorial that goes over creating POCO configurations using the Fluent API. I was unaware this was available in EF and had only seem Data Annotations previously.

After watching this tutorial I read probably a dozen articles/topics on "Fluent API vs. Data Annotations". It seems like the consensus is that Fluent API allows you to separate your "dumb" domain POCOs from your persistence logic. The glaring problem I see with that is that you don't get the front-end validation that come along with the Data Annotations. I have yet to read a response from the pro-Fluent API crowd as to how this is tackled.

When using Fluent API, are you forced to duplicate your logic in the configuration files as well as on the front-end?

mellis481
  • 4,332
  • 12
  • 71
  • 118

1 Answers1

1

Yes, when using the fluent API approach it's likely that you will end up duplicating entity metadata in your front-end validation.

One big benefit of the fluent API approach is that your entities have no dependency on Entity Framework. This issue has been fixed in .NET 4.5 by moving the data annotation attributes to the System.ComponentModel.DataAnnotations assembly.

It's also common with complex entity models, that your front-end will not actually use the domain entities, but will use DTOs or some front-end specific model projected from the entities. In this case you are going to lose your data annotation attributes anyway.

Tim B
  • 2,340
  • 15
  • 21
  • Ahh. I see. Your second paragraph is a moot point w/ the new version of EF, but as far as your third paragraph goes, your front-end (Views) shouldn't be using the domain POCOs directly anyway. They should be using view models. I think my problem in realizing this has been because almost every EF tutorial/video I've seen uses the most basic example (a single project, using domain objects in views, etc) which are so far away from what real projects are like, it becomes unhelpful. In either case, thanks! – mellis481 Aug 02 '13 at 12:38