Why we do not document code?

This post led to a hot technical discuss today.

Why we do not document code?

If we’re serious about the piece of code, we have to write some useful documentation. Amazingly, I have noticed among many of my colleagues that the hard part is not coming from laziness! It’s the full understanding of a system/component that makes you feel sluggish to write a decent document for your code.

Some business processes are really complex to rephrase them into human language. Of course, the fear of any misunderstanding gap seems to be the source of all ignorance.

FubuMVC - Upgrade to 0.9 Note

Just a quick note:

I upgraded my fubuMVC project to version 0.9.1.. and it couldn't load my WebForms. After some emailing with the group, I figured out my fubuRegistry needs to get my view-engine's config. Unfortunately, it's not mentioned in the techie documents.



So, Please add this statement right into your FubuRegistry class if you use 0.9. versions and above.
It is noteworthy to say that FubuMVC is going to hit the 1.0 very soon.

FubuMVC - Nuget

FubuMVC now is available via Nuget.Org.

You can install this package in Visual Studio's Package Manager Console by this command.

Install-Package FubuMVC

if you are not interested in Fubu's other packages( Spark, FubuMVC.Validation...) you can get the minimal version on nuget.

Install-Package FubuMVC.References

Also, a nice document is designed by the development team.
Take look at FubuMVC Documents.

EF Code-First in the shape of NHibernate - Profiling

ORM tools made datacentric programs too easy to develop, but if it's been used without care, it will soon face a disaster in terms of SQL efficiency.
Microsoft proposes a tool for the developers who wants to know what is happening under the hood in EF.
It means, all SQL statements and information can be traced and logged in a file based on the developer's desire.
All you have to do is :
   1. Install two wrappers for EntityFramework from Nuget.org

•    CommunityEFProviderWrappers.EFProviderWrapperToolkit
•    CommunityEFProviderWrappers.EFTracingProvider

   2. Create a DbConnection object that is configured to log SQL staements like the one below and inject this object into DbContext.

var context = new DbContext(CreateTracingConnection(connectionString, "System.Data.SqlClient");
        detail implementation of CreateTracingConnection is written below.


   3. EnableTracing for data context.

      ((IObjectContextAdapter)this).ObjectContext.EnableTracing();

By this approach, you definitely know what commands are being executed when your application is running in debug mode.

EF Code-First in the shape of NHibernate - Using (5/5)

Once your database is built, using EF Code-First for the rest of the project is as easy as NHibenate. Same Patterns like Repository, Unit of work... can be applied to the codes in your application.

Even there is no difference between Code-First or Database-First (the one that you create your model out of your database) mode in your business logic code.

By this approach your model (Genrally POCO [ Plain Old CLR Object]) is first initialized and database is built as the result of your object model. By some tricks like migrations you can narrow your database recreation down to some field name modification or changes in size.

EF Code-First in the shape of NHibernate - Migrating Changes (4/5)

One of the hassles every application developer might have faced during his/her career is how to best synchronize changes between model and database schemas (versioning problem).Several solutions have been proposed but I personally believe ORM tools should care about this problem in their hearts.

Microsoft's EntityFramework.Migrations is a tool designed for going over such hurdles. Although it has some incompatibilities between different versions of EF, but it looks promising. Technically speaking, the tool checks current object model with the one on database( if any). Any differences are detected and written to a script file and finally migration tool is in charge of running the script file and applies changes to database. 

Note : All you have to do to install is write Install-Package  EntityFramework.Migrations in package manager console.  

There 2 ways to create migration, Manual Migration that uses code-based migration and Automatic. I will pick automatic which is very easy to use.

All we have to write is :

    public class Settings : DbMigrationContext<YourContext>

    {

        public Settings()

        {

            AutomaticMigrationsEnabled = true;

            SetCodeGenerator();

            AddSqlGenerator();

        }

    }

Note: replace YourContext with your DbContext class in your project.


Two commands are handy in migration panel.

• Add-Migration name that generates a script file for all the changes between object model and database schema.  
• Update-Migration that pushes all pending changes to the database and applies them on database.

EF Code-First in the shape of NHibernate - Mapping Files (3/5)

Once the DbContext is configured, Let's take a look at how can EF comprehend our model and generates schema out of it.

Simply EF looks through all classes listed in OnModelCreating() method, and based on some conventions, it realizes that which classes has to be converted into SQL tables, their SQL column attributes(name, type, size..) and how they are associated with each other. i.e One to One, One to Many, Many to Many.

For those NHibenate users who are pretty familiar with FluentNHibernate.Org, that is really easy for them to switch to EF conventions.

Here's the what DocumentMap looks like:


As you see all mapping classes should inherit from EntityTypeConfiguration. This class accepts a generic class and it has to be our domain class.
By looking at the class internals, you' ll see some conventions are used :
   1. HasKey gets primary key for the table as lambda expression.
  2. Property gets Number property in Document model as SQL column and set as not null.
  3. ToTable sets the name of generated table.

All other properties are converted to SQL columns based on EF conventions.( Note; the EF conventions can be modified manually but that's beyond the purpose of this series)

Same thing applies to DoumentDetailMap, but there is a little tricky point in setting up One-Many in mapping class.




as it clearly shows, HasRequired get Document object in DocumentDetails class then it calls WithMany that related Document to DocumentDetails. Foreign keys can be included in config and at the end, relation can be set to delete all children orphaned rows.