I am using the database first approach with entity framework, when i used to work on the default template the database tables were mapped using the ObjectContext, so i used to create #partial classes & [MetadataType(typeof ) to apply the data annotation ,, but when i start using the Dbcontext code generation template to map the database tables i found that it will create .tt folder in my Model area were i find that i can apply the data annotation directly to the .cs classes themselves without the need to create partial classes as in objectcontext case.
Currently the data annotations are working fine,, but would my approach cause me problems i am not aware of and i should create partial classes as i used to do with the Objectcontext ?
BR
In general, you shouldn't edit generated code because changes you make will be overwritten on re-generation. This is why most generators emit partial classes.
The best practice for your situation would be to create a new file in your solution with another partial class declaration. In that file, add the MetadataType attribute to the class, and add your property-level validation attributes to the "buddy" class (the one referenced in the attribute). This allows you to use validation attributes on the generated properties and, should your model/database change, you can still re-generate your model classes without losing them.
For example, your new file might look something like:
[MetadataType(typeof(PersonMetadata))]
partial class Person
{
// Add logic to the generated class in here.
public string FullName
{
get { return FirstName + " " + LastName; }
}
}
class PersonMetadata
{
// Add attributes to the generated properties in here.
[Required]
public string FirstName { get; set; }
}
Create the same partial classes to define your metadata OR you can simply reverse engineer your existing database using the Entity Framework Power Tools so you have POCO classes. Then you can use the fluent API (you'll see the validations it adds for you) instead of data annotations to give you server side validation.
If you want client side, then you can still apply them to your models, as they wont be regenerated every time you compile .
however - I would recommend you create ViewModels and use AutoMapper to map between your EF objects and viewmodels. Then you can apply your annotations directly to your ViewModels.
My understanding of your situation is that you reverse-engineered your Database-First style to a Code-First style. If your context class inherits from DbContext, you are in Code-First style now (unless there is some strange hybrid possible, which I don't know about!).
In code-first, there is really no point of creating partial classes for data annotations, IMO.
Related
I have an interface defined as:
public interface ICMDBContext
{
DBSet<Building> {get;}
DBSet<Room> {get;}
more DBSet methods...
string Save()
}
I have the DBContext generated class named CMDB_DataModelContainer.
I have a partial class CMDB_DataModelContainer which implements ICMDBContext which looks like this (And yes, both are in the same namespace):
public partial class CMDB_DataModelContainer : ICMDBContext
{
string Save() { implemenation... }
}
Everything compiles all fine and dandy, but when I try to create a controller and use CMDB_ModelConatiner as the context class (creating a Strongly-typed controller) I get the error
There was an error generating 'CMDB.Domain.Models.CMDB_DataModelContainer'. Try rebuilding your project.
I removed the partial class and was able to create the controller. Any ideas why this would happen?
To add, the DBContext classes are in a separate project.
The fact it is in a separate project doesn't matter. I created a test project with DBcontext class and the MVC3 app in same project and still a no go.
I suppose a question to ask is if anyone has actually setup a repository when using Model first approach. I am finding myself running into problem after problem trying to apply this pattern when using model first.
If you want to recreate the issue, just make an MVC 3 (or 4, I used 3). This is what I did for a test to recreate it myself.
Add a new ADO.Net Entity Data Model.
Create two entities: Taco and Filling
Add a "name" scalar property to each.
Add association m <---> m
Create a new folder named "Partial" in the models folder.
Add a new class - the class should be named the same as the Context class (if you left default names it should be Model1Container) and in the same namespace.
e.g.
public partial class Model1Container
{
}
- Add a new controller "TacoController" as strongly typed against, you guessed it, Taco, and using the Model1Container as the context class. Voila, reproduced. Yes, I like tacos.
As you have probably discovered, removing(/renaming) the partial class, creating the controller and then reinstating your partial class seems to be an adequate workaround. As for why:
One of the times I tried I noticed something strange: a new declaration had appeared in the partial class file I'd created:
public DbSet<Taco> Taco { get; set; }
I can only speculate that VS is getting confused by the partial class files - it finds the partial class file you created, doesn't see the DBSet declared, tries to add it and then gets in a tizzy because that's too many tacos.
Chris
I'm working on an MVC3 project I have created my database on SQL server 2008 then I add it using entity data model, now I have the .edmx I don't want to generate the code of the classes because till now it's not stable and I don't feel the need to do that except to make the validations
I'm wondering if there is a way to make validation directly using the .edmx without generating the code of classes
Need server and client side validation
Cheers
You can't do it from edmx. You can however have classes that add the metadata to the edmx generated classes.
This adds a metadata containing class to the class that was generated by the edmx:
[MetadataTypeAttribute(typeof(CustomerMetadata))]
public partial class Customer
{
}
and then you have the metadata class which has the metadata attributes:
internal sealed class CustomerMetadata
{
public int ID;
[Required]
[StringLength(60)]
public string Name;
}
Edit:
EF generates all it's classes as partial. That means you can add functionality in a different file to the same class. We use this feature to add an attribute telling .net that there's a class that has the metadata information. In this case the class with the metadata for the Customer class is CustomerMetadata.
It has all the properties that you want decorated with metadata. In this case ID is not actually required to be there.
(I would have added this as a comment but I don't have enough reputation points yet)
Be sure that the namespace in your partial class exactly matches the EF-generated class's namespace, including the correct case.
I'm creating an MVC 3 application that needs to establish data validation rules at runtime based on external data (e.g. Required, MinimumLength, MaximumLength). It seems natural to use Data Annotations in MVC 3, however the property attributes that provide validation metadata are set at compile-time.
Is there a pattern to use Data Annotations with metadata provided at runtime?
Example:
public string Text { get; set; }
public void SetIsRequired(string propertyName, bool required)
{
// Somehow find the property 'propertyName' and create/remove a RequiredAttribute
// on that property
}
...
SetIsRequired("Text", true);
I'm aware of TypeDescriptor, but don't see an option to modify attributes of a property of an instance (only class level attributes on an instance, or property level attributes for a type).
It seems natural to use Data Annotations in MVC 3
Not for me. I never really liked data annotations due to their declarative nature. And doing validation in a declarative way limits capabilities. I have always liked and use FluentValidation.NET.
You could probably use the IDataErrorInfo interface (which MVC can consume) to write your custom, dynamic, validation rules.
I have several thoroughly unit-tested and finely crafted rich DDD model classes, with final immutable invariants and integrity checks. Object's instantiation happens through adequate constructors, static factory methods and even via Builders.
Now, I have to provide a Spring MVC form to create new instances of some classes.
It seems to me (I'm not an expert) that I have to provide empty constructor and attribute's setters for all form's backing classes I want to bind.
So, what should I do ?
Create anemic objects dedicated to form backing and transfer the informations to my domain model (so much for the DRY principle...) calling the appropriate methods / builder ?
Or is there a mecanisms that I missed that can save my day ? :)
Thank you in advance for your wisdom !
The objects that are used for binding with the presentation layers are normally called view models and they are DTOs purposed toward displaying data mapped from domain objects and then mapping user input back to domain objects. View models typically look very similar to the domain objects they represent however there are some important differences:
Data from the domain objects may be flattened or otherwise transformed to fit the requirements of a given view. Having the mapping be in plain objects is easier to manage than mappings in the presentation framework, such as MVC. It is easier to debug and detect errors.
A given view may require data from multiple domain objects - there may not be a single domain object that fits requirements of a view. A view model can be populated by multiple domain objects.
A view model is normally designed with a specific presentation framework in mind and as such may utilize framework specific attributes for binding and client side validation. As you stated, a typical requirement is for a parameterless constructor, which is fine for a view model. Again, it is much easier to test and manage a view model than some sort of complex mapping mechanism.
View models appear to violate the DRY principle, however after a closer look the responsibility of the view model is different, so with the single responsibility principle in mind it is appropriate to have two classes. Also, take a look at this article discussing the fallacy of reuse often lead by the DRY principle.
Furthermore, view models are indeed anemic, though they may have a constructor accepting a domain object as a parameter and a method for creating and updating a domain object using the values in the view model as input. From experience I find that it is a good practice to create a view model class for every domain entity that is going to be rendered by the presentation layer. It is easier to manage the double class hierarchy of domain objects and view models than it is to manage complex mapping mechanisms.
Note also, there are libraries that attempt to simplify the mapping between view models and domain objects, for example AutoMapper for the .NET Framework.
Yes you will need to create Objects for the form to take all the input, and the update the your model with this objects in one operation.
But I wont call this objects anemic (especially if you do DDD). This objects represent one unit of work. So this are Domain Concepts too!
I solved this by creating a DTO Interface:
public interface DTO<T> {
T getDomainObject();
void loadFromDomainObject(T domainObject);
}
public class PersonDTO implements DTO<Person> {
private String firstName;
private String lastName;
public PersonDTO() {
super();
}
// setters, getters ...
#Override
public Person getDomainObject() {
return new Person(firstName, lastName);
}
#Override
public void loadFromDomainObject(Person person) {
this.firstName = person.getFirstName();
this.lastName = person.getLastName();
}
// validation methods, view formatting methods, etc
}
This also stops view validation and formatting stuff from leaking into the domain model. I really dislike having Spring specific (or other framework specific) annotations (#Value, etc) and javax.validation annotations in my domain objects.
I have a linq-to-sql class. I have a property "Password" for which I want to call the underlying ASP.NET Membership provider. Thus, I do not want this property written out directly but via my own code. I basically want to create a facade/proxy for this property such that I may use the underlying membership provider or a custom stored procedure.
I want to accomplish without modifying the LINQ-TO-SQL designer generated code, if at all possible.
It is possible. You can add your properties and methods to linq generated class using partial class mechanism. Linq generated classes are marked partial so you can add class members with:
public partial class YourLinqClass
{
// your methods and properties. refer linq properites and methods with "this."
// example:
public string Password
{
get
{
int id = this.UserId;
string password = // ... get password
return password;
}
set
{
// ...
}
}
}
You have to place the partial class in the same namespace as the rest of dbml.
The best option is to remove the property from the designer and write it in code, in the partial class, as described by PanJanek.
However, if you do it this way, you are pursuing a bad design. You're introducing a dependency into your entity class that breaks layer encapsulation. Entity classes shouldn't know about providers any more than they know about the DataContext that loads them. They aren't really meant to be anything more than containers for data going in and out of the database.
You should consider making a separate class that wraps the entity, the context, the username provider, and whatever other services you require, and in that class retrieve the username and do the required operations to your entity.
It looks like it might be possible to create a custom DataContext to handle this situation.
http://weblogs.asp.net/scottgu/archive/2007/07/11/linq-to-sql-part-4-updating-our-database.aspx
There are partial methods for the individual properties as, well and an OnValidate method.
In my case, I think the best solution is to throw an exception in the property changing method and add a public method for setting this individual property. This solution while not perfect will avoid touching the SQL generated code, where the property could be set to readonly or the setter removed.
Other suggestions welcome.