Gil Fink on .Net

Fink about IT

News

Microsoft MVP

MCPD Enterprise Applications Developer

Gil Fink

My Linkedin profile

Locations of visitors to this page

Creative Commons License

Blog Roll

Hebrew MSDN Articles

Index Pages

My OSS Projects

Closing Another Year

Closing Another Year

Another year of writing isMy Blog is Two Years Old
over. A lot has happened in
my life during the last year.
Here are some highlights:

  • I have a new baby boy
    at home :-)
  • I received a MVP award from
    Microsoft.
  • I started to work in a new 
    company – Sela Group.
  • And many more.

Few Stats About my Blog

  • Subscribed readers by Feedburner: ~350 (first year – ~115).
  • Total blog posts: 219 (first year – 113).
  • Total comments: 421 (first year – 216).
  • Total trackbacks and pingbacks: 368 (first year – 81).
  • Google Analytics summary of last year:
    • Page Views: 178,589 (first year – 57,539).
    • Unique Pageviews: 154,821 (first year – 49,714).
    • Average time on site: 03:12 (first year – 02:42).
  • Top Three Posts Ordered by Number of Views

    Tell me how can I Improve My Blog

    I’d like to hear from you, the readers of my blog, how can I improve it.
    feel free to leave comments such as which topics would you like me to
    write about? which things add value to you when you read my blog? or every
    comment that you want to share with me in regard to my blog.

    DotNetKicks Image
    Back to Basics – Using MasterType Directive

    Back to Basics – Using MasterType Directive

    This post is Back to Basics – Using MasterType Directive
    a result of
    a question that
    I got from one
    of the developers
    that I work with.
    The question was
    how to use master page properties from an ASP.NET page.

    Setting the Environment

    The first thing that you want to do is to expose the properties
    as public in the master page. For example this is code behind
    of a simple master page that exposes the IsPageEnabled property:

    public partial class Site1 : MasterPage
    {
        #region Properties
     
        public bool IsPageEnabled { get; set; }
     
        #endregion
     
        #region Page events
     
        protected void Page_Load(object sender, EventArgs e)
        {
        }
     
        #endregion
    }

    The MasterType Directive

    When we want to use the property in a page which reference the
    previous master page we need to put the inside of it the MasterType
    directive:

    <%@ MasterType VirtualPath="~/Site1.Master" %>

    This directive declare that the master page of a page is strongly type.
    By that simple directive we gain access to the master exposed public
    properties and methods through the Master property of the page.
    For example this is how in the page I’ll call the IsPageEnabled property of
    the master page:

    public partial class WebForm5 : Page
    {
        #region Page Events
     
        protected void Page_Load(object sender, EventArgs e)
        {
            Master.IsPageEnabled = true;
        }
     
        #endregion
    }

    The markup of the page I use:

    <%@ Page Title="" Language="C#" MasterPageFile="~/Site1.Master" AutoEventWireup="true"
        CodeBehind="WebForm5.aspx.cs" Inherits="TestModalDialog.WebForm5" %>
     
    <%@ MasterType VirtualPath="~/Site1.Master" %>
    <asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1" runat="server">
    </asp:Content>

    Summary

    Lets sum up, when we use master pages we can expose properties
    and methods for the pages. We use the MasterType directive in the
    page in order to create a strong type master page inside of it. By
    doing that we can pass data from the page to its master.
    Very easy and very useful.

    DotNetKicks Image
    Entity Framework Context Lifetime Best Practices

    Entity Framework Context Lifetime Best Practices

    In this post I’mEntity Framework Context Lifetime Best Practices
    going to write
    about one of the
    major decisions
    that you need to
    take when you use
    ORM tools like Entity Framework.
    This decision is the context lifetime.

    The Problem

    Context lifetime is a very crucial decision to make when we
    use ORMs. Since the context is acting as an entity cache (it holds
    references to all the loaded entities for change tracking and
    lazy loading purpose), it may grow very fast in memory consumption.
    Also this behavior can cause a memory leak because if we don’t
    dispose our context it will have references to all the loaded entities
    and by that they will never be collected by the Garbage Collection.
    Another problem that raise its ugly head is keeping a context lifetime
    to long or to short. If we dispose the context after every database
    manipulation or query we won’t enjoy the all the features it holds
    (for example change tracking).
    For example the following code disposes the context very fast and
    shows the problem I talk about:

    using (var context = new SchoolEntities())
    {
        context.AddToDepartments(department);
        context.SaveChanges();
    }

    On the other hand, keeping a long running context is also bad practice.
    Sometimes I see developers that use the context as a singleton in their
    system. This is very bad since as I wrote it can cause a memory leak.
    Also it is bad habit because you will have transactions for longer time 
    than you should have them. Business transactions and connection
    management should be used in very short bursts and only as they are
    needed.

    My Rules of Thumb

    • Web applications – use the context per request. Since in web
      applications we deal with requests that are very short but holds
      all the server transaction then they are the proper duration for
      the context to live in. We will enjoy all the functionality of the
      context and it won’t hang up very long.
    • Smart clients (Win Forms/WPF etc) – use a context per form.
      Since we don’t want to have the context as a singleton for our
      application we will dispose it when we move from one form to
      another. In this way we will gain a lot of the context’s abilities
      and won’t suffer from the implications of long running contexts.

    Summery

    Managing context lifetime is very crucial decision that we need to take
    at the starting of every project. My rules of thumb is context per
    request and context per form lifetimes.

    DotNetKicks Image
    Using Unit of Work Pattern with Entity Framework

    Using Unit of Work Pattern with Entity Framework

    In a previous postUsing Unit of Work Pattern with Entity Framework
    I explained how
    to create a
    simple repository
    on top of
    Entity Framework.
    In this post I’ll explain the Unit of Work pattern and how
    we can use it with our data access layer.

    What is Unit of Work Pattern?

    In his famous and developer must read book
    Patterns of Enterprise Application Architecture”, Martin Fowler
    defines the Unit of Work as “Maintains a list of objects affected by a
    business transaction and coordinates the writing out of changes and the
    resolution of concurrency problems.”
    What it means is that a unit of work is a context/session/unit object that
    tracks the changes of business entities during one business transaction. It is
    also responsible for the manage of concurrency problems when they occur.

    How to Use The Pattern?

    As in the repository pattern we will start with an interface which was
    suggested by Martin Fowler:

    public interface IUnitOfWork<T>
    {
        void RegisterNew(T entity);
        void RegisterDirty(T entity);
        void RegisterClean(T entity);
        void RegisterDeleted(T entity);
        void Commit();
    }

    As you can see we register changes of entities inside the unit of work
    and in the end of every transaction we commit it using the commit method.
    In all the major ORMs out there you get all that functionality within the
    session/context objects. It is the unit of work object that holds the details
    of every change you do to an entity. Since this is the case you don’t
    have to have all the four register methods when you use frameworks
    like Entity Framework, NHibernate or other ORMs.
    In my example I’m going to use the following unit of work interface:

    public interface IUnitOfWork<T>
    {
        void RegisterNew(T entity);
        void RegisterDeleted(T entity);
        void Commit();
    }

    Entity Framework Example

    Lets return to the example of the repository I used in the previous post.
    I can transform the DepartmentRepository that I’ve built into a
    unit of work that handle departments like this one:

    public class DepartmentRepository : IRepository<Department>,
        IUnitOfWork<Department>, IDisposable
    {
        #region Members
     
        private SchoolEntities _context;        
     
        #endregion
     
        #region Ctor
     
        public DepartmentRepository() 
        {            
            _context = new SchoolEntities();
        }
     
        #endregion
     
        #region IRepository<Department> Members
     
        public Department GetById(int id)
        {
            return _context.Departments.
                Where(d => d.DepartmentID == id).
                FirstOrDefault();
        }
     
        public Department[] GetAll()
        {
            return _context.Departments.ToArray();
        }
     
        public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)
        {
            return _context.Departments.Where(filter);
        }
     
        #endregion
     
        #region IUnitOfWork<Department> Members
     
        public void RegisterNew(Department entity)
        {
            _context.AddToDepartments(entity);
        }
     
        public void RegisterDeleted(Department entity)
        {
            _context.DeleteObject(entity);
        }
     
        public void Commit()
        {
            _context.SaveChanges();
        }
     
        #endregion
     
        #region IDisposable Members
     
        public void Dispose()
        {
            if (_context != null)
            {
                _context.Dispose();
            }
            GC.SuppressFinalize(this);
        }
     
        #endregion
    }

    This is a really simple example of how to implement the pattern.
    There are a lot of other examples in the web like in the following link:
    Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork

    Summary

    Lets sum up, every ORM that respect itself (like Entity Framework) includes
    implementation for the unit of work pattern. If we want to add our abstraction
    layer which include a unit of work then we need to create our implementation.
    We will start with an interface such as the one that Martin Fowler suggested.
    Then it is our responsibility to track changes and to persist all the work that was
    done in a time period as a transaction and also manage concurrency issues. 

    DotNetKicks Image
    To Use OSS or Not to Use?

    To Use OSS or Not to Use?

    This post is a result of a very big discussion I had with a customer
    that I’m currently consulting for. The discussion started because a
    project reached its testing phase and to my surprise the QA team
    worked with… (don’t be shocked) a primitive excel file to manage
    bugs. The testing phase was taking to long because of things like
    concurrency (two users can’t edit the excel file at the same time),
    synchronization of the same file and many other multi-user or files problems.
    Since in my opinion the situation couldn’t go on like this, I contact one
    of the managers and suggested to use a bug management system instaed
    of using the file. I got the well known answer –
    there is no budget and the organization won’t be buying this kind of systems.
    I then offered to use BugTracker.NET or other OSS that offer fine bug
    management systems. Using such systems will be with no cost so the budget
    issue won’t be a problem and the benefits are clear.
    This is were I hit the wall!
    Apparently there is a very clear guidance in the customer’s organization that
    restrict the use of OSS. Even further, the manager came to me and told me that
    in his opinion as a consultant I can’t advise to use an OSS (even though I
    suggested a tool that I used in the past and it proved itself).
    He also told me that he thinks that it can reduce my credibility if I offer to use
    open source projects.
    Here is my thoughts – bullshit.
    There are times that OSS can help you to go forward and not to remain in
    Middle Ages. I know that there are pros and cons for using OSS which can
    help you decide whether to use them or not in a project but to absolutely
    reject a solution because it’s an OSS is stupidity.
    In the end they still use the excel file and the schedule for going to production
    was postponed in two weeks because of the slow testing phase. Of course it
    postponed another project that rely on this project in four weeks. 
    The delay in the schedule is going to cost the organization more money
    then buying a bug management system license.
    Making bad decisions can come at you.

    DotNetKicks Image
    The Regulator

    The Regulator

    Yesterday, I reviewed a regular expression that The Regulator Logo
    was written by one of the developers and
    I needed to improve it since it wasn’t performing
    the appropriate thing. Since I know The Regulator
    tool, I opened it and in 5 minutes I came up with this
    regular expression which validate Israeli phone/cellular
    numbers:

    ^0(5[012345678]|6[47]|[23489]){1}(\-)?[^0\D]{1}\d{6}$

    With The Regulator I created and checked the expression and
    then implemented it in the application.

    What is The Regulator?

    The Regulator is a free tool that was written by Roy Osherove.
    It’s purpose is to help us create regular expressions and also
    to test them inside The Regulator application. It allows the
    building and verifying of regular expressions and also includes
    testing functionality that enable us to see a display of the hierarchical
    tree that will be generated by match, replace and split operations.
    The following screen show the main screen of The Regulator:
    The Regulator

    Where Can You Download It?

    You can download the tool from here.

    Enjoy!

    DotNetKicks Image
    Error CS0029: Cannot implicitly convert type Using WSDL Tool

    Error CS0029: Cannot implicitly convert type Using WSDL Tool

    Today I wasError CS0029: Cannot implicitly convert type Using WSDL Tool
    asked by one
    of developers
    I work with to
    check an error
    he got after he
    generated a proxy class with the wsdl.exe tool from a third party
    wsdl he got. The error was generated in runtime when he tried to use
    the generated class and it was something like:

    Unable to generate a temporary class (result=1).
    error CS0029: Cannot implicitly convert type 'A' to 'A[]'

    After searching in the internet I found that there is a known bug
    where the xsd/wsdl generators don’t produce the correct proxy
    class. The problem was that the generated class was produced with
    a method call that return a jagged array ([][]) instead of a simple array
    of type A ([]). In runtime the serialization of an array doesn’t
    produce a jagged array and also the opposite and therefore it generate
    the exception only in runtime.

    How to fix the Problem?

    After generating the C# proxy class from the given wsdl check that
    the generated class is correct and if not manually fix all the
    problems. The fix for our problem was to remove one of the two []
    from the jagged array that was generated.

    I hope it will help you if you stumble on this error in the future.

    DotNetKicks Image
    Entity Framework at Sela Open House

    Entity Framework at Sela Open House

    Yesterday, even though I’m currently sick (I have the flu), I delivered
    a session about Entity Framework at Sela Open House event.
    In the session I introduced Entity Framework, talked about the
    EDM, explained how to query and manipulate data and in
    the end talked about what is coming in EF4.
    I want to thank all the attendees who came to hear the session.
    As I promised, I uploaded the session slide deck and demos to
    my SkyDrive and you can download them from here.

    Enjoy! 

    DotNetKicks Image
    Don’t Repeat Yourself

    Don’t Repeat Yourself

    Today while I was Don’t Repeat Yourself
    doing code review
    I found myself
    writing a new
    generic function
    instead of one
    piece of code
    that was repeating
    itself in the
    developer’s code.
    When you write
    code sometimes you
    have to duplicate
    some piece of code.
    When it occurs, this
    is the best time to
    think of refactoring your functionality.
    A lot has been written about DRY principal this post is my opinion
    about it.

    The DRY Principal

    Don’t Repeat Yourself or DRY is a very good practice when we are
    writing code. It helps to produce a more reusable and maintainable
    code. When you don’t follow DRY whenever a functionality that
    you “Copy & Paste” all over your code will change you’ll have
    the taste of one of the developer horrors -
    to find all the places in the application that you duplicated the
    functionality and to update it. Not being able to find all the places will
    result in a non functioning application or other errors. Since changes 
    always occur during the life time of an application following the
    simple DRY principal can prevent you a lot of headaches.

    Example

    Lets look at the code that I helped the developer to refactor:

    private void ValidateContactDetails()
    {
       var validator = ValidationFactory.CreateValidator<ContactDetails>();
       var results = validator.Validate(uc.DataSource);
       if (results.Count > 0)
       {
          ValidationError.DisplayError(results.First().Message);
       }
    }

    This code validate a contact details entity using the
    Validation Application Block. Since the code was repeated in more
    than one place but with different object types and different data
    sources then I created the following method instead:

    public void ValidateEntity<T>(object dataSource)
    {
       var validator = ValidationFactory.CreateValidator<T>();
       var results = validator.Validate(dataSource);
       if (results.Count > 0)
       {
          ValidationError.DisplayError(results.First().Message);
       }
    }

    Now instead of duplicating the functionality of validation with a
    lot of functions that perform the same thing we have only
    one function that perform the same thing but is more generic.
    This is much better!

    Summary

    Lets sum up, to achieve code quality you shouldn’t repeat yourself.
    Copy & Paste” helps to create code faster but it has the ability
    to make your code very poor when it is being used without thinking.
    Whenever you repeat some piece of code all over the place it’s a very big
    sign for you that you need to refactor your code. One of the horrors of
    a developer is to find all the duplications in a code base and change
    some simple functionality.
    So don’t repeat yourself!

    DotNetKicks Image
    Table Per Concrete Type Inheritance in Entity Framework

    Table Per Concrete Type Inheritance in Entity Framework

    The last inheritanceTable Per Concrete Type Inheritance in Entity Framework
    mapping
    that I’m
    going to write about
    is the Table Per Concrete
    Type inheritance
    (TPC). This
    inheritance type is
    very rare but you should
    be aware of how to create it when it is needed.
    You can read about TPT and TPH from here and from here.

    Table Per Concrete Type Definition

    The TPC inheritance occurs when we have two tables with
    overlapping fields in the database. Such a thing can occur
    in situations that we create an history table that all historical
    data is transferred from the main table to it.
    In the example I’m going to use the following database schema:
     Database Schema
    As you can notice I have a Department table and a DepartmentHistory
    table. They both have overlapping fields.

    TPC Example

    The following steps will help you to understand how you can create
    a TPC inheritance mapping. I’m going to use the exactly database
    from the first figure I showed.

    Step 1
    The first step is to create the Entity Data Model from the database.
    Here is the EDM I’m going to use in the example:
    Entity Designer Diagram

    Step 2
    Create an inheritance from OldDepartment (which is mapped to
    DepartmentHistory table) to Department entity. In order to do that
    in the designer surface click on the right mouse button and use the
    Add –> Inheritance menu item.
    Add Inheritance Mapping
    In the Add Inheritance dialog make the Department the base entity
    and the OldDepartment derived entity.
    Add Inheritance
    After you do this the model will look like:
    Entity Designer Diagram 1
    Step 3
    Since we have overlapping tables remove all the properties of OldDepartment.
    These properties are going to be taken from the Department entity.
    The model should look like:
    Entity Designer Diagram 2 

    Step 4
    Now it is time for the mapping. In the Mapping Details View you
    will notice that the only available property for mapping is the
    DepartmentID property. Map it in the OldDeprtment.
    Map DepartmentID
    All the other mapping details will be needed to be edit manually
    in the Xml editor.

    Step 5
    Open the model in Xml editor and seek for the mapping of OldDepartment
    entity in the MSL part. You will see that the Departments set is mapped
    as:

    <EntitySetMapping Name="Departments">
      <EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Department)">
        <MappingFragment StoreEntitySet="Department">
          <ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" />
          <ScalarProperty Name="Administrator" ColumnName="Administrator" />
          <ScalarProperty Name="StartDate" ColumnName="StartDate" />
          <ScalarProperty Name="Budget" ColumnName="Budget" />
          <ScalarProperty Name="Name" ColumnName="Name" /></MappingFragment></EntityTypeMapping>
      <EntityTypeMapping TypeName="IsTypeOf(SchoolModel.OldDepartment)">
        <MappingFragment StoreEntitySet="DepartmentHistory">
          <ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" />
        </MappingFragment>
      </EntityTypeMapping>
    </EntitySetMapping>

    Copy all the property mappings from Department to OldDepartment
    mapping and that is all. The code will look like:

    <EntitySetMapping Name="Departments">
                <EntityTypeMapping TypeName="IsTypeOf(SchoolModel.Department)">
                  <MappingFragment StoreEntitySet="Department">
                    <ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" />
                    <ScalarProperty Name="Administrator" ColumnName="Administrator" />
                    <ScalarProperty Name="StartDate" ColumnName="StartDate" />
                    <ScalarProperty Name="Budget" ColumnName="Budget" />
                    <ScalarProperty Name="Name" ColumnName="Name" /></MappingFragment></EntityTypeMapping>
                <EntityTypeMapping TypeName="IsTypeOf(SchoolModel.OldDepartment)">
                  <MappingFragment StoreEntitySet="DepartmentHistory">
                    <ScalarProperty Name="DepartmentID" ColumnName="DepartmentID" />
                    <ScalarProperty Name="Administrator" ColumnName="Administrator" />
                    <ScalarProperty Name="StartDate" ColumnName="StartDate" />
                    <ScalarProperty Name="Budget" ColumnName="Budget" />
                    <ScalarProperty Name="Name" ColumnName="Name" />
                  </MappingFragment>
                </EntityTypeMapping>
              </EntitySetMapping>

    Step 6
    Test the created inheritance. The following code will print out
    all the departments and then all the old departments in the
    database.

    using (var context = new SchoolEntities())
    {
        var departments = context.Departments.OfType<Department>();                
        foreach (var department in departments)
        {
            Console.WriteLine(department.Name);
        }
     
        var oldDepartments = context.Departments.OfType<OldDepartment>();
        foreach (var department in oldDepartments)
        {
            Console.WriteLine("old: {0}", department.Name);
        }
    }
    Console.ReadLine();

    Summary

    Lets sum up, in the last post about inheritance types I explained
    what is Table Per Concrete Type Inheritance and showed how
    to map it in EF. There are more ways to customize the conceptual model
    that we have in EF like using Complex Types, DefiningQuery and etc.
    Even though, inheritance mapping is very useful in order to express our
    conceptual model as we see it in Object Oriented.


    DotNetKicks Image
    Table Per Hierarchy Inheritance in Entity Framework

    Table Per Hierarchy Inheritance in Entity Framework

    In the second Table Per Hierarchy Inheritance in Entity Framework
    inheritance mappings
    tutorials I’m going to
    write about the
    Table Per Hierarchy
    (TPH) inheritance
    mapping. If you want to read
    about the first mapping I showed go to the Table Per Type post from
    here.

    Table Per Hierarchy Definition

    In TPH the inheritance tree is create through one table only.
    The TPH inheritance depends on a conditional mapping which is
    defined by a condition such as a discriminator database field.
    The condition is used to define records as different types.
    For example, in the following database schema the Person table
    includes a TPH inheritance:

    Database Schema
    As you can see the table holds two different fields from two
    different types: HireDate (which belong to a professor type)
    and EnrollmentDate (which belong to student type). The table
    also includes an integer discriminator field which is called PersonType.
    When PersonType equals 1 the person type is a professor and when 
    it is 2 the type is student.

    TPH Example

    The following steps will help you to understand how you can create
    a TPH inheritance mapping. I’m going to use the exactly database
    from the first figure I showed.

    Step 1 
    The first step is to create the Entity Data Model from the database.
    Here is the EDM I’m going to use in the example:
    Entity Designer Diagram 
    We are going to use only the Person entity for the TPH demonstration.

    Step 2
    From the designer surface use the Add –> Entity and add two entities:
    Professor and Student.
    Add New Entities
    Make Person entity their base type.
    Add Professor 
    After that the model should look like:
    Entity Designer Diagram 1 

    Step 3
    Move the HireDate property to the Professor entity and the
    EnrollmentDate property to the Student entity. Also remove
    the PersonType property from Person because it is going to
    be our discriminator field. 
    Entity Designer Diagram 2 

    Step 4
    In the Mapping Details View map the Student entity and the
    Professor entity to the Person table. Also map the relevant
    properties to the fields in the database. The following figure
    shows how to map the student entity:
    Map The Student Entity 

    Step 5
    Add a condition to the entities using the Mapping Details View. The
    condition should be on the PersonType field and should indicate that
    if PersonType equals 1 the person is a Professor type and if the
    PersonType equals 2 the person type is a Student. the following
    figure shows how to do it in the Student type:
    Add Condition 

    Step 6
    Since Person is a base type which is an abstract type we need to
    indicate that it is abstract. Point on the Person entity and press
    F4 to open it’s properties dialog. In the dialog turn the abstract
    flag to True.
    Person Properties

    Step 7
    Test the inheritance mapping. The following code will print the
    number of people in the database and also the number of professors
    and students:

    using (var context = new SchoolEntities())
    {
        var query = from person in context.People
                    select person;
        Console.WriteLine("All People: " + query.Count().ToString());
     
        var query1 = from student in context.People.OfType<Student>()
                    select student;
        Console.WriteLine("Students: " + query1.Count().ToString());
     
        var query2 = from proffesor in context.People.OfType<Professor>()
                    select proffesor;
        Console.WriteLine("Professors: " + query2.Count().ToString());
    }
     
    Console.ReadLine();

    Summary

    Lets sum up, in the post I explained what is Table Per Hierarchy
    inheritance
    and showed how we can create that inheritance
    in a specific model. The use of TPH is common and sometimes
    can lead to very big tables which include a lot of fields. Since it is
    a bad habit to create very big tables, I suggest to use TPH with TPT.
    In the last post in this series I’m going to explain what is
    Table Per Concrete Type inheritance and how to use it in EF.

    DotNetKicks Image
    Table Per Type Inheritance in Entity Framework

    Table Per Type Inheritance in Entity Framework

    The first inheritanceTable Per Type Inheritance in Entity Framework
    mapping I’m going to
    show is called
    Table Per Type
    or TPT. Before
    I start with the example
    lets define what is TPT.

    Table Per Type Definition

    TPT is an inheritance described in the database with separate tables.
    Every table provides additional details that describe a new type
    based on another table which is that table’s parent.
    In the following database ERD the OnlineCourse table is a concrete
    type of Course:
    Database Schema 
    As you can see the CourseID of both Course and OnlineCourse table
    are the same identity.

    TPT Example

    The following steps will help you to understand how you can create
    a TPT inheritance mapping. I’m going to use the exactly database
    from the first figure I showed.

    Step 1
    The first step is to create the Entity Data Model from the database.
    Here is the EDM I’m going to use in the example:
    Entity Designer Diagram
    As you can see I created an EDM with only the relevant tables for
    simplicity. Also, pay attention to the association that was created
    (1 - 0..1) between the tables. This is happening because of the use of
    the same ID in both of the tables.

    Step 2
    After we have our EDM ready to work we need to define the
    inheritance instead of using the created association.
    First remove the association by clicking on the association in
    the designer and pressing delete. Then from the designer surface
    press on the right mouse button and use the Add –> Inheritance
    to open the Add Inheritance dialog.
    Open Inheritance Dialog
    In the Add Inheritance dialog make the Course the base entity and
    the OnlineCourse the derived entity like in the following figure:
    Add Inheritance
    We you finish you will have an inheritance arrow between OnlineCourse
    and Course like:
    Entity Designer Diagram 1

    Step 3
    After we have created the inheritance we need to fix our model.
    The CourseID field in the OnlineCourse isn’t relevant anymore since
    it is part of the base entity. So let remove it. Also we need the
    CourseID database field to something which is the parent CourseID:
    Fixing The Model
    That is it for this kind of model. There will be more model fixing when
    we have associations to other entities.

    Step 4
    Test the created model. The following piece of code will print the
    count of the online courses we have in our database:

    using (var context = new SchoolEntities())
    {
        var query = context.Courses.OfType<OnlineCourse>().Count();
        Console.WriteLine("Number of online courses: {0}", query);
        Console.ReadLine();
    }

    As you can see I’m using the OfType method which enable me to
    do operations on derived types.

    Summary

    Lets sum up, I showed how to use Table Per Type inheritance in
    Entity Framework. As I wrote in a previous post this kind of mapping
    isn’t used only by EF and it is also used by other ORMs. In the
    next post in this series I’m going to describe and show the Table
    Per Hierarchy inheritance
    .

    DotNetKicks Image
    Entity Framework Inheritance Types

    Entity Framework Inheritance Types

    In Sela SDP Entity Framework Inheritance Types
    conference I was
    asked if Entity
    Framework
    supports
    inheritance mapping.
    The answer I gave
    was a small 25 minutes improvised session which I gave after
    the EF4 session I had. In the following three posts I’m going to
    explain the main three inheritance ways that you can use with EF.
    These ways are supported in other ORMs as well.

    Why to Use Inheritance?

    One of the ORMs main purposes is to enable us the domain developers
    to create a conceptual model that resemble our way of thinking about
    our domain. Since we use Object Oriented principals like inheritance to
    express the domain there is a need to create the inheritances in
    the data storages that we use. But how can we create the inheritance
    graph in a database and map it within the ORM?

    The Main Inheritance Ways

    There are three main ways (or combinations of these ways):

    As I wrote, I’ll explain every one of these ways and show EF examples
    in a follow up series.

    DotNetKicks Image
    Using Repository Pattern with Entity Framework

    Using Repository Pattern with Entity Framework

    One of the tools Using Repository Pattern with Entity Framework
    for reaching for
    persistence
    ignorance
    is to
    build a facade between
    the data access layer and
    your business logic. Such facade will prevent the knowledge of
    how the data access is working and with which technology. That
    abstraction can be achieved by using the Repository Pattern.
    In the post I’ll show how you can use the Repository Pattern in order
    to make an abstraction layer on top of Entity Framework.

    The Repository Interface

    When we want to use the Repository Pattern we
    start with an interface which will be our data access facade.
    I’ll be using the following interface in my example:

    public interface IRepository<T>
    {        
        T GetById(int id);
        T[] GetAll();        
        IQueryable<T> Query(Expression<Func<T, bool>> filter);                                
    }

    This interface only include some of the functionality which I’ll
    put in a repository. You may notice that I removed any CUD
    (Create/Update/Delete) operations. In a follow up post I’ll show
    how to implement these operations by using the Unit of Work
    pattern.

    A Repository Implementation

    The following is a naive implementation for a department repository:

    public class DepartmentRepository : IRepository<Department>, IDisposable
    {
        #region Members
     
        private SchoolEntities _context;        
     
        #endregion
     
        #region Ctor
     
        public DepartmentRepository() 
        {            
            _context = new SchoolEntities();
        }
     
        #endregion
     
        #region IRepository<Department> Members
     
        public Department GetById(int id)
        {
            return _context.Departments.
                Where(d => d.DepartmentID == id).
                FirstOrDefault();
        }
     
        public Department[] GetAll()
        {
            return _context.Departments.ToArray();
        }
     
        public IQueryable<Department> Query(Expression<Func<Department, bool>> filter)
        {
            return _context.Departments.Where(filter);
        }
     
        #endregion
     
        #region IDisposable Members
     
        public void Dispose()
        {
            if (_context != null) 
            { 
                _context.Dispose(); 
            } 
            GC.SuppressFinalize(this);
        }
     
        #endregion
    }

    This is a naive implementation since I hold a context inside my
    department repository. A better solution will be to create a
    context helper that will be used in order to create contexts when
    they are needed. After we have the implementation we can start
    using it.
    The following code demonstrate how we can use the department
    repository:

    IRepository<Department> repository = new DepartmentRepository();
    foreach (var department in repository.GetAll())
    {
        Console.WriteLine(department.Name);
    }
     
    foreach (var department in repository.Query(d => d.Budget > 150000))
    {
        Console.WriteLine("department with above 150000 budget: {0}",
            department.Name);
    }            
    Console.ReadLine();

    Why to use the Repository Pattern?

    There are a lot of reasons for using the Repository Pattern.
    For example:

    • Testability. Using the pattern we can create stubs that
      can replace the real data access objects. This can
      help us to test our business logic without concerning what the
      data access is doing.
    • Abstraction. Using the pattern we create an abstraction above
      our data access functionality. This abstraction can help us when we 
      want to change the implementation of the data access without
      affecting our business logic code. For example, I had to change
      implementation of data access with a call to a web service. Using
      the pattern I only needed to change the object that I used and that is
      it.
    • Dependency Injection. Using the pattern we can use DI containers to
      inject the relevant object that we want to use in the code.

    Summary

    Lets sum up, the Repository Pattern is a very useful pattern to use
    when we build data access layers. Like all other patterns sometimes
    it can be an overkill in abstraction (in particular in small and simple applications).
    In the post I showed one way to create a repository on top of Entity Framework.
    I could have used any other data access frameworks as well and this is the beauty
    of the pattern. In a follow up post I’ll explain what is the Unit of Work pattern and
    will continue building the repository I used in this post so stay tuned.

    DotNetKicks Image
    Defining Custom Functions in Entity Framework

    Defining Custom Functions in Entity Framework

    During the SDP conferenceDefining Custom Functions in Entity Framework
    I have been asked about the  
    use of functions inside the EDM.
    This post will try to answer one
    such question of how to define
    a custom function in EF.

    Custom Functions in Entity Framework

    One of the capabilities of EF since EF1 was the creation of custom
    functions inside the SSDL part of the model. After their creation
    we could consume them like other imported functions.
    In that way we could define functions in the model which were
    acting like stored procedures but without being a part of the database.
    This of course means that in order to use this feature we needed to
    write some XML code inside the SSDL.

    Defining a Custom Function

    The first thing to do is to open the model in XML editor and to
    add a Function element inside the Schema element in the SSDL part of the
    XML. Inside the Function element we add a CommandText element which
    will hold our T-SQL expression. We can also add to the function parameters.
    The following XML fragment shows an example of a custom function:

    <Function Name="GetCoursesByCredit" IsComposable="false">
      <CommandText>
        SELECT *
        FROM Course
        WHERE Credits = @Credits
      </CommandText>
      <Parameter Name="Credits" Type="int" Mode="In"></Parameter>
    </Function>

    After the creation of that function we can use the Add Function Import
    wizard to import that function to the ObjectContext:
    FunctionImport Wizard
    and then to run a test like this one to see the function in action:

    using (var context = new SchoolEntities())
    {
        var query = context.GetCoursesByCredit(3);
        foreach (var course in query)
        {
            Console.WriteLine(course.Title);
        }
        Console.ReadLine();
    }

    Summary

    EF enables us to add custom SSDL functions to our model. These
    functions can be handled like other imported functions (UDFs or
    stored procedures). This feature should be used rarely in my opinion
    and only when there is a T-SQL functionality that we must have but
    EF doesn’t support.

    DotNetKicks Image
    More Posts Next page »