Archive for July, 2011
Data validation is a very important subject when developing applications. You have to assure good quality and high integrity of your data for being able to exploit it correctly. You need to avoid storing any corrupt, incomplete or wrong data in your database which will most certainly lead to misbehavior within your applications.
The following example shows how to implement a constraint on the Name property (required / string length between 5 and 20 characters) via Data Annotations.
Validation is automatically done when calling the Save method to persist any changes applied to your objects in memory. But you may as well do it before by calling the GetValidationErrors method.
Lets say when the code above is executed it will fail due to validation errors. In this case error messages will be displayed for each constraint that was not respected. In our example we defined that the Name property should have a minimum string length of 5 characters, but the property only contains 4 characters. Since we did not define a specific error message, a generic error message will be displayed for this validation error.
There are multiple Data Annotations that allow for type validation, format validation, regular expression matching, etc….
The new version of Entity Framework supports the usage of Data Annotations. Data Annotations are used for validation purposes and also for mapping definitions between code and columns in the database.
All annotations are implemented as attributes which can be found in the System.ComponentModel.DataAnnotations namespace (same attributes that are used for ASP.NET MVC validation purposes).
- [Key] – Column(s) that define the Primary Key in the database table
- [StringLength] – Minimal and maximal string length (only used for validation purposes not as database constraints)
- [MaxLength] – Can be used instead of [StringLength] to just define the maximal string length of a column
- [ConcurrencyCheck] – Flag that indicates that concurrency checks are activated for the column
- [Required] – Flag that indicates that a value is required for the column (column is flagged as not null)
- [Timestamp] – Flag on time stamp columns which is used for concurrency checks
- [Column] – Specify the name of a column (default property name), can also be used to define the column position
- [Table] – Specify the name of a table (default class name)
- [DatabaseGenerated] – Flag that indicates that the value is filled by the database (possible values are Computed, Identity, None)
- [NotMapped] – Is used to define a property in the class that does not get generated in the database.
- [ForeignKey] and [InverseProperty] – Column(s) that are defined as Foreign Keys
Following an example for the usage of Data Annotations that was applied to our company domain. The Manager class does not currently contain any properties that could automatically be identified as primary key.
This tutorial introduces the new functionalities that were added to Entity Framework 4.1. It shows the differences between the approaches and acts as an introduction to these new features.
Database First & Model First
The Database First approach is interesting when the database already exists. You use Visual Studio and the Entity Framework Designer to generate the C# and VB.NET classes which reflect the existing database model.
You may then change relations and structures using the Designer (or the XML mapping files) to further optimize the model. The priority is the database – the code and the model are only secondary.
The Model First approach is important when you begin from scratch. You start with the entity model and use the Entity Framework Designer to design the relations and the entities.
Then you generate the C# and VB.NET classes and also the database from within Visual Studio. The priority is the model – the code and the database are only secondary.
When your priority is the code and you want to begin from scratch without any existing schemas or XML mapping files using source code, then the approach is called Code First.
You simply create your domain classes and Entity Framework 4.1 will easily allow to use them with the database and the future model.
You use a context and are able to execute Linq2Entities queries in no time ! You may even take advantage of the change tracking features !
Entity Framework handles all of the background work and manages the interaction with the database. All the classes that are used during runtime are auto-generated.
In this case the configuration is not read from XML files but instead read from the configuration of the DbContext object in memory.
J’ai présenté dernièrement comment lancer une analyse NDepend au sein d’un workflow de build TFS 2010. Cette intégration dans TFS 2010 en plusieurs étapes que je vous propose peut très bien s’appliquer à d’autres produits que NDepend, j’ai choisi NDepend car c’est un excellent outil qui apporte une grande valeur ajoutée aux builds de Team Foundation Server.
Des règles critiques pour lever des alertes…
Outre les statistiques et métriques sur le code qu’il sait calculer, une des forces de NDepend est de pouvoir exécuter des règles représentant des exigences sur le code, les fameuses “CQL rules” (Code Query Language). Elles sont réparties en catégories (qualité, design, performance, effets de bord, nommage, etc.) et permettent de mettre en évidence les bouts de code qui ne les respectent pas.
Certaines de ces règles sont dites “critiques” et leur rôle est de lever une alerte suffisamment forte pour générer une erreur dans un build ou une analyse automatisée. Je vous propose de prendre en compte ces alertes de deux manières différentes et de faire évoluer notre Workflow de build en conséquence.
Separate implementation and object interfaces
Sometimes used, useful to decouple an abstraction from its implementation and to be able to modify them independently.
Note that the Bridge pattern has nearly the same structure as the Adapter Pattern. But it is used when designing new systems instead of the Adapter pattern which is used in already existing systems.
1 / 5
UML Class Diagram:
- The abstract Repository class defines the interface that all inheriting refined Repository classes will use for object management purposes.
- Note that the operations within the Repository classes define high-level operations.
- The refined Repositories extend the basic functionalities and implement the execution code that uses the implementation classes. They should contain specializations which only apply to specific Repositories.
- The abstract DataObject class defines the interfaces of the implementation classes. Note that the abstract Repository and the abstract DataObject classes can have completely different interfaces.
- The concrete DataObject implementations contain the code that executes all the low-level operations.
- Note that the methods within the Repository class could also call multiple methods in the implementation classes (1 to * relationship).
- In the last step we add some code to test the software design and the Bridge implementation.
- When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.
Match interfaces of classes with different interfaces
Often used and easy to implement, useful if classes need to work together that have incompatible existing interfaces.
1 / 5
UML Class Diagram: