EF Feature CTP5: Validation

re: EF Feature CTP5: Validation

Alex — Mon, 03 Oct 2011 20:53:19 GMT

It seems ValidateEntity is not called within the same database transaction. Therefore, there may be race conditions with other entities in the database.

For instance, with a unique property validator.

protected override DbEntityValidationResult ValidateEntity(DbEntityEntry entityEntry, IDictionary<object, object> items) {

var validation_state = base.ValidateEntity(entityEntry, items);

if (entityEntry.Entity is User) {

var entity = (User)entityEntry.Entity;

var set = Users;

//check name unique

if (!(set.Any(any_entity => any_entity.Name == entity.Name))) {} else {

validation_state.ValidationErrors.Add(new DbValidationError("Name", "The Name field must be unique."));

}

return validation_state;

}

re: EF Feature CTP5: Validation

Dave — Tue, 13 Sep 2011 14:52:53 GMT

Why don't you add these attributes for us when doing database first? OR at least have an option to do so. I don't want to modify the generated code constantly, and perhaps get it wrong if the db changes.

re: EF Feature CTP5: Validation

Pawel — Tue, 19 Jul 2011 19:14:41 GMT

@James: There is a way to pass your own objects to custom validation and this is the way to pass your context. You do it by overriding DbContext.ValidateEntity method and invoking the method from the base class with non-null dictionarry of custom objects. Take a look at this post:

blogs.msdn.com/.../ef-4-1-validation.aspx

There is a section called "Custom Validation Sample: Uniqueness" that does exactly that.

re: EF Feature CTP5: Validation

James — Mon, 18 Jul 2011 15:20:29 GMT

Is there anyway to get hold of the current context whilst using a custom validation attribute. I am trying to doa unique validation attribute, but cannot see how I get the current context. Unfortunately it is no good creating a new context as this will not contain the 'local' list of items pending insert - which also need to be validated against.

re: EF Feature CTP5: Validation

Martin F — Sun, 03 Jul 2011 19:54:12 GMT

Are you seriously suggesting that people should now start validating user input in the database model ?

I think it is fine validating before saving to the database as an extra layer of protection securing that database rules are upheld, but these errors should _NEVER_ be reported to the user, it should be logged and the developer should be notified. At best this should be something which is caught when running your tests.

User input validation should happen before it reaches the database, for example in a view model.

re: EF Feature CTP5: Validation

Jason — Wed, 23 Mar 2011 16:46:08 GMT

I really, really hope this feature will be extended for Model First and Database First.

re: EF Feature CTP5: Validation

Derek — Sat, 08 Jan 2011 00:16:29 GMT

I've been trying CTP5 out and everything I've done works great locally. When connecting to a remote database though, I had to specify the connectionString in the constructor for the DbContext as I couldn't get it to work using the connectionString name.

re: EF Feature CTP5: Validation

Pawel — Tue, 04 Jan 2011 18:50:17 GMT

@tmsmith: I answered your question on the forum. Here is the link: social.msdn.microsoft.com/.../2108079c-8160-460e-b703-1800bd910679

re: EF Feature CTP5: Validation

Ludwig — Wed, 22 Dec 2010 20:55:51 GMT

@Rik: I have implemented a DDD architecture with EF 4 CTP 5 as the repository implementation in the infrastructure layer. De domain layer is completely independent, has its own tracking and validation mechanism. In my case, because I also own the client, the domain model itself is exposed in the service layer and as such, I can just reuse the domain model on the WPF client, where it is encapsulated by the view models (using MVVM). It also means I reuse every domain logic on back-end and client. Of course, in enterprise applications you would typically not expose the domain model, but instead create specific data contracts, according to the needs of the clients. So in this architecture, EF is only known in the infrastructure layer, where it belongs. Concerning EF: good practise is to have a context per unit of work, but unfortunately EF cannot deal with this very well; so I spent a number of weeks trying to find out a way to make this work, and eventually succeeded (basically I replay the changed recorded by the domain model), but there's room for improvement in this area - and when EF would actually work well in a disconnected scenario one day, I just need to adapt the repository implementation. (If you want to discuss this further, we could always exchange mail or something.)

re: EF Feature CTP5: Validation

Rik — Wed, 22 Dec 2010 10:56:27 GMT

@Ludwig we are having similar problems with EF and would be interested to hear what you would propose as an alternative until EF's design become more usable.