[Tutorial] Code First with Entity Framework 4.1 Part3: Data Validation

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….

[Tutorial] Code First with Entity Framework 4.1
Part3: Data Validation

[Tutorial] Code First with Entity Framework 4.1 Part2: Data Annotations & Code First Fluent API

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).

Common attributes:

• [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.

By adding the [Key] attribute to the ManagerCode property you define that this property should act as primary key. You furthermore add a concurrency check as well as a minimum and maximum length setting for the Name property.

In the following example we add a required constraint to the Department class by applying the [Required] Data Annotation to the Name property.

Data Annotations are definitely easy to use but it  is preferable to use a programmatic approach that provides much more flexibility.  This approach is based on the Code First Fluent API.

You have to implement the OnModelCreating method within the derived CompanyContext class. Then you define your constraints applicable to your domain within this method programmatically.

When using this approach you may even describe relations between tables and columns. The following code example defines that the Manager entity contains a Department entity. The key that relates both is the DepartmentId.  If the Manager entity is deleted then the corresponding Department must also be deleted  (CascadeOnDelete).

[Tutorial] Code First with Entity Framework 4.1
Part2: Data Annotations & Code First Fluent API

[Tutorial] Code First with Entity Framework 4.1 Part1: Introduction to the Code First approach

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.

Code First

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.

Code First allows:

• Developing without the need to use the Designer or XML mapping files
• Defining the objects of the model based on a POCO (Plain Old CLR Objects) approach

Explanation:

• Design and implement a company domain with Managers, Collaborators and Departments.

• Create your classes using a standard object oriented approach and using inheritance when appropriate.
• Use the POCO approach for your classes where possible.
• Note that for being able to use the auto-mapping feature for the primary keys you need to have named your class properties like this : [Classname]Id.

• Entity Framework 4.1 allows connecting those POCO classes with the database very easily by using the ObjectContext class (and in particular the DbContext class).

• The last step consists of defining the connection to the database within the web.config or app.config files. Note that EF will search for the connection string that has the same name as the class that was inherited from the DbContext class. You may however define a different name ("CompanyContext" in our example).

[Tutorial] Code First with Entity Framework 4.1
Part1: Introduction to the Code First approach

[Tutorial] Common Design Patterns in C# 4.0 Part8: Bridge Pattern

Pattern Name:
Bridge Pattern

Short Description:
Separate implementation and object interfaces

Usage: 
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.

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• 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.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part8: Bridge Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part7: Adapter Pattern

Pattern Name: 
Adapter Pattern

Short Description:
Match interfaces of classes with different interfaces

Usage:
Often used and easy to implement, useful if classes need to work together that have incompatible existing interfaces.

Complexity: 
1 / 5

UML Class Diagram:

Explanation:

• The TradingDataImporter class acts as a client using classes with an existing Connector interface.

• The abstract Adapter class defines the interface that the client class knows and that it can work with.
• The concrete Adapter classes convert the interface of the incompatible classes into an interface the client expects. They make different existing interfaces work together.

• Here are some examples of different adaptee classes that implement different interfaces. However, the client expects a generic interface that they currently don’t provide. That is why they get wrapped by the concrete adapter classes to make them compatible with the client.

• In the last step we add some code to test the software design and the Adapter implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:

http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part7: Adapter Pattern