study nildana's blog

The official blog of all the blogging that is done by the folks at study nildana

bidding two of our authors good bye - part 2

At the sea, the beach remains where it is. The rocks on the beach also remain where they are, enduring a lot of wear and tear over time. Unfortunately, the same cannot be said of tides and waves. When the tides and waves, come at you, its a glorious sight. It's beautiful and it is grand. Then, the waves and tides have to recede back, return to their source. One feels sad to watch the tides go away because they bought so much joy and happiness only some time ago.

That is how I feel as two more of our bloggers ( previous bloggers good bye can be read here ) Prathibha and Shringar, have decided to take leave from their duties here at study nildana. I have told countless times as to how, without students, study nildana would not be where it is today. For that, and so much more, study nildana and I are indebted to them.

Thank you to both of you, and god willing, I will find your replacements sooner rather than later :)

Building a web app – Part 3 of X

In my previous blog post, I discussed creating a brand new project.

The actual project is available at this link -

All the work that is done in this particular blog post, will be available in the commit called ‘Part 3 of X’

In this post, I will write about some UI changes that I did to make the web app look more like the project we are building. At this point, the project shows the standard ASP DOT NET things. For instance, the copyright marking says ‘ © 2016 - My ASP.NET Application’ Like this, there are so many ‘generic things’. I will have to change those things.

My first step is to go to the Views > Shared >_Layout.cshtml. This file is where the entire web app gets its cool menus (like when you reduce the width of the web app, the menu suddenly appears) and this is also where we can edit all the menu titles and other stuff. Best to check the commit details to see all the things I have changed.

At the end of the post, some stuff about the app (mostly visuals) have been fixed. Next post, I will talk about adding some models.

Building a web app – Part 2 of X

In my previous post, I talked about building a simple project. So, this is where I actually build it. Each part title is linked to particular commit. Each commit will have the name identical to the blog post that you are reading it.

The actual project is available at this link -

All the work that is done in this particular blog post, will be available in the commit called ‘Part 2 of X’

In this part, the very first thing I did was to go ahead and create a new project. In Visual Studio, I chose the ‘Web’ portion in the very first portion that comes up. Then, I chose the part says ‘web’ again, and here I selected MVC. Further, I check marked the option called ‘individual accounts’ as I will be building some kind of an authentication system into this web app. Further, I unchecked ‘application insights’. I also unchecked ‘deploy to azure’. Both of these unchecked steps are something that are useful but they will be stories for another day.

Once the project was created (depending on your computer speed, this may take 30 seconds to 3 minutes), I built it to make sure that there are no errors. If there are any errors, then you should fix your visual studio installation because, this new project creation should ‘simply work’. If there are no errors, run the app and you should have the website running in a browser. I personally use Firefox but you are free to use any browser of your choice. Visual Studio by default will try to run it in Edge.

Once the web app is running, I want to check if the database is working. You know, the default website SQL server express that is part of this thing. So, I went ahead and registered a dummy account. Once the registration is complete, then I logged out and logged back in. Doing these steps is essential because this tells you that the app has proper access the local database. If you run into database errors, then you should check your SQL server express installation and fix that first.

I did not run into any errors. So, at this point, I have a fully functional but empty web app running.

In the next part, I will make some UI changes to get things kicking.

Issues you might face

While pushing the project to the bit bucket, I ran into this issue where the repo end would hang up on me unexpectedly. This probably happened because I was pushing too many files and of large sizes (my guess) because the error does not come when the files being pushed are small size. I had to go with this command to get the error to go away.

Error - fatal: The remote end hung up unexpectedly

Solution - git config http.postBuffer 524288000

Building a web app – Part 4 of X

In my previous post, I talked about making some essential UI changes. Here let’s look at adding some models.

The actual project is available at this link -

All the work that is done in this particular blog post, will be available in the commit called ‘Part 4 of X’

This is where the main crux of the project starts. The idea behind this mini project is to allow students to store their marks in the database. Here are the elements, that I believe that a standard student should have in our web app.

·         Name (obviously)

·         Age (of course)

·         Email address (this will be the same email address that the student will register/login to see her/his own marks)

·         Marks (I am assuming that we just have one marks and nothing else in this school. It’s not reality but so is the rainbow)

With the above data in mind, I will now add a ‘student’ model into the project.

    public class student


        //this is the unique ID automatically set by EF

        public int ID { get; set; }


        //the name of the student

        public string student_name { get; set; }


        //the age of the student

        public int student_age { get; set; }


        //email of the student

        //note that the student has to use this exact same email address when she/he registers on the web app to see her marks

        //since we cannot process login/registration process without email address, we cannot allow student entries

        //to be made to the database unless

        //so this becomes a mandatory field.

        //that is why I am using the Required attribute


        public string student_email_address { get; set; }


        //marks scored by the student

        public string student_marks { get; set; }


For the above data model, I will need to add a database set.

    //now need to get the context that will work with the database

    public class studentDbContext : DbContext


        //connection string to be used

        public studentDbContext() : base("studentDbContext")





        //DbSets that are the tables

        //table for students

        public DbSet<student> student_sets { get; set; }


        //this is more about appearance rather than functionality

        //prevents table names from being pluralized

        protected override void OnModelCreating(DbModelBuilder modelBuilder)




Now that I have the data model, and the database set, I can now use the cascading feature of visual studio and build the basic CRUD stuff for students.

Before I can do that, I will have to include a connection string. For that, I use a simple string. Remember back when I ‘checked’ individual accounts. When you did that ran the application, a connection string was already included in the web.config file of the project. So, here is how the automatically generated connection string looks like.

<add name="DefaultConnection" connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-demo_asp_dot_net_1-20160928033935.mdf;Initial Catalog=aspnet-demo_asp_dot_net_1-20160928033935;Integrated Security=True"      providerName="System.Data.SqlClient" />

In the above data set for students, you will notice that the context is defined as studentDbContext.

<add name="studentDbContext"  connectionString="Data Source=(LocalDb)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\aspnet-demo_asp_dot_net_1-20160928033935.mdf;Initial Catalog=aspnet-demo_asp_dot_net_1-20160928033936;Integrated Security=True"      providerName="System.Data.SqlClient" />

I made changes in getting the above connection string to store the student tables (just to note, the first connection string relates to the storage of user accounts), the first being change the name. The second was change the Initial Catalog name to something else. Now, I can do the cascading with the controller and get the CRUD views for the student DB.

In the next blog post, I will use the identity management system, and also the Seed method (available from the entity framework system) to build a default set of roles as well as users.

CRUD in asp dot net

You have already learnt about CRUD in an earlier blog post. Read about it here. In this post, I am going to shed some light on the CRUD implementation in asp dot net.

The essential concept of CRUD (which is to create, read, update and delete stuff) is maintained in asp dot net. The extra coolness here (rather the coolness offered by visual studio) is the scaffolding magic that happens.

You see, when you are building CRUD around your model, you can take two routes.

·         The first route is that you manually do the View (with all the HTML and Razor code) as well as the Controller (with all the linking to the View and necessary database context c sharp code) yourself.

·         The second route is to allow the scaffolding to do its magic and add a standard CRUD mechanism into your web app. All you need to do is provide the database context and the model, and that’s it.

Personally, I like to go through the second option because, it relieves of having to do everything that is necessary to get the CRUD functionality into the system. This saves me a lot of time. Further, it also allows me to leverage on all those countless man hours Microsoft spent on getting this CRUD code right. In addition to this, I can freely modify (and of course, by the project is ready to deploy a lot of this default code will be changed to suit our own unique requirements) both the controller and view, with the explicit knowledge that the system won’t break down.

Getting this CRUD scaffolding to work is pretty straight forward. Right click on the ‘Models’ folder in solution explorer. Go to ‘Add’ and then navigate to ‘Controller’. Then, Select from the options, the one that says ‘MVC5 Controller with views, using Entity Framework’. Now, choose a model (for which you want CRUD), then choose the database context and finally give it a controller name of your choice. After this, sit back and watch the magic happen.

Object Relational Mapping ORM

In an earlier post, I have written a little bit about the relationship that exists between databases, data models and the middle guy in between (or middle girl if you prefer) who may connect these two. It is that middle girl (or middle guy) I am talking about here.

These middle agents are called Object Relational Mappers or Object Relational Mapping systems or some other, much more inventive name that you could come up with as you read this blog post. There are two words here that will help us understand them better.

·         Object – This refers to the objects (instances of the data model classes that we have defined in our application) that we are using to store data in our application.

·         Relational - This refers to the Relational Models that is used in all databases that we use these days.

As the title indicates, Object Relational Mapping or ORM is all about mapping the stuff in the objects (in the application code) into that of the database schema.

I am no expert on ORM, but I understand enough to get by at my work. ORM allows the application developer to work with almost no knowledge about the workings of the database. For instance, it is possible for an application developer to build an entire web application using asp dot net and EF without ever having to write a single line of SQL query.

That is because, the developer (such as you and I) will write code in c sharp, which is what we are good it. When it comes to database related stuff like CRUD (read about CRUD here), you have systems like LINQ (which allows you to write queries to your database context) and EF (which acts like the middle agent and connects your application to the actual database). Thanks to these two systems – LINQ and EF – not a single line of SQL needs to be written.

All this sounds great for folks who have nightmares about SQL (and those beautiful, glorious and sometimes insanely complicated SQL queries) itself. By eliminating the requirement to work with SQL directly, a lot of stuff becomes easy.

Further, when the data model (inevitably) changes during the application development and its life, the corresponding database schema also needs to be changed. When using an ORM, it is possible to simply ask the ORM to update the database to reflect the changes in the data model. EF comes with a system of migration. Through migration, it is possible to push the changes to the database, as they are done to the data model.

The same EF also provides with a Seed functionality which is useful if you are looking to push data default data (Data that must already be there for essential functionality) to the database.

Overall, ORM and specifically EF has a lot of benefits. Obviously, as with anything in life, there must be some issues as well. One issue that I have found is that we are all at the mercy of the ORM system when it comes to mapping objects to schema. If there are somethings that the EF cannot do, then we simply cannot do it, and we may have to resort to talking directly to the database. Further, if the EF system should ever be abandoned by the developer, we will be done for. This problem won’t happen when you are directly talking to the database, because SQL queries today will still work tomorrow. However, EF today when dropped may stop working entirely.

Overall, personally, I prefer to work with ORM and EF. They make my life easy and I am going to trust Microsoft (the provider of EF) not to kill EF anytime soon.

Building a web app – Part 1 of X

So far, I have written and blogged about plenty of articles related to asp dot net. There is no possible way that I have covered every possible concept related to asp dot net. In all fairness, even the topics that I have blogged about don’t cover everything. Yet, with what little I have shared in my posts, it is possible to learn the essentials. Then, use this essential knowledge and build a functional web app or website or web service or web-whatever that you are planning to build.

So, think of this blog post (and several sequel posts that follow this one), as a mini project. You can find the final source code as usual at our study nildana repo. Click here to go the source code. You will find lots of notes and comments in the solution itself that will be self-explanatory.

The Project

Okay, this web app I am building here is a simple school management app. It has the following type of users.

·         Visitors who simply visit the site. (Non-Registered Users)

·         Visitors who register. (Registered Users)

·         Registered users who are approved to be students. (Student Users)

·         Registered users who are approved to be teachers. (Teacher Users)

·         Registered users who are approved to be Admins. (Admin Users)

The story for this web app is simple. We have a small school, which has some students, teachers and a IT admin. The web app keeps track of the student details. The requirement is as follows,

·         Non-Registered Users, should be able to see the home page and not much else.

·         Registered Users, should be able to see some extraneous pages (like About, Contact) but not much else.

·         Registered Users who are approved as Student Users should be able to see their own details and nothing else.

·         Registered Users who are approved as Teacher Users should be able to see all the student details and nothing else.

·         Registered Users who are approved as Admins, should be able to see all the User Details and all the student details. Further, the admin user will be in a position to ‘approve’ users to different user levels.

[Note: As with any real world project, the project requirement may be changed as the project moves through development]

The above is the primary requirement of the project. Other details are to be assumed on the fly (like the actual student data that will be stored in the database, servers to be used, the appearance of the actual website) during the project development. Of course, do note that in a real web app development, you usually don’t move past the requirement stage until all the details are nailed and document to the last detail. Of course, there are uncountable companies out there (and I have seen with my own eyes to boot) where live projects start development even before the basic requirements are nailed down. Then again, well, you know, that’s life.

Anyway, this is a mini project and I am only nailing down what is essential to our project, and allowing everything else to be flexible. Find here, all the blog posts, in the order of development, how this web app could be developed.

[Note: This whole project will be updated as it is developed, pushed to bit bucket, and published here over time]

Find the entire project – the source code – at this bit bucket link.

Find the blog posts specifically related to this project below.

·         Step 1 – creating a new project.

What is this CRUD

I have written a whole lot of articles of asp dot net MVC earlier. You can check them out here. Obviously, when you are using a technology such as asp dot net MVC, you are thinking of building some sort of a web application. An application implies that some data is being served by the server, some data is being sent back to the server from the user client (which is the browser) and stuff is being processed. That means, there is a database in play, and that database is being manipulated by the application directly (where in your app talks directly to the database in question) or indirectly (wherein your app talks to middle person such as entity framework or EF and the middle person then interacts with the database).

So, a database is in play. The moment you think of database you think of CRUD, which stands for Create, Read, Update and Delete.

The titles alone should be explanation enough to indicate what they mean to a database. However, a little explanation for those who love extra detail.

For the sake of completion, and examples stuff, I will imagine that we have a web application, and that has a database. The application is for a water bottle factory, and the database is for keeping track of things raw material stock, water bottle stock and employee related stuff and so on.

C for Create

Create usually means, creating a new row in the database. Of course, create could also mean, create a new table and creating a new schema and so on. However, during the normal operation of the application, you are most likely to be creating new rows (in an existing table more like) than anything else.

So, when you do a C operation, you are creating rows in a table.

For example, I have a table that stores the different employees who work at the factory. Suppose a new employee has joined the company. I will probably have to create a new row in the employee table.

R for Read

Once tables have been created, you would probably wish to read the data that is stored in these tables. That is Read and R. It must be included here that Read could mean a lot of things. You could be reading an entire table worth of data. You could be reading a particular row (based on some value in a column) from a table. You could be reading multiple rows spread across multiple columns.

So read is anytime you read stuff from the database.

For example, say the manager wants to know about all the employees in the company. I will ‘read’ all the rows from the table and provide that information to the manager.

U for Update

Once you have created sufficient amount of data in the database, you will notice that you will always have reasons to modify existing data in the database. Although modify is a good word to use when dealing with a database, it can be misleading because deleting a row (or an entire table) can also be considered as modifying.

Update strictly applies to scenarios where some part of the database being modified, while keeping the other parts intact.

For example, one of the employees comes and tells me that when he joined, he gave the wrong date of birth. Then, she provides me with the correct date of birth. I will then go ahead and update it in the row that belongs to that employee.

D for Delete

Ah, the last part of CRUD. As the name implies, deleting rows is what D stands. Just like create, it is possible to delete entire tables, and even entire databases. However, the D here usually refers to the activity of deleting rows in a table. This could mean deleting a single row or multiple rows.

For example, an employee comes to me and says that she is leaving the company. In that case, I will probably have to delete her row from the table. Of course, in a real world, I will simply move her row from this table to some other table called ex-employees. Of course, that would involve making a copy of the row, creating a new row in another table, and moving all this data. Finally, deleting the existing row in the table.

So, there you have it. CRUD for you!

Data Models and Database and Entity Framework

In the blog posts about MVC, I have talked about Models (which are actually data models and you can read about them here). I have also talked about databases and I have written about entity framework (which you can read right here).

Now, it seems like I have been talking about three different things. Which also means, it is easy to get lost between all these three concepts. They are all pretty different and yet, there are all connected. It’s kind of like the move matrix which seems to have something to say about everything from singing to cooking to living to working.

First up, let’s talk about database. Database is the physical server where you actually store your data. Databases are usually located on servers (that means, when you create a database on your own laptop or PC, you are essentially turning it into a sever). There are many brands of servers, and most of them are similar with their basic functionality. You have Microsoft Server (my personal favorite, of course), Oracle, IBM, MySQL, Postgre and so on and so forth. There are way too many brands of servers today and everybody has their favorites and dislikes.

Whenever an application has to work with a database, it will use what is called as a connection string. Then, using that connection string, your application will connect to it, and then you do your CRUD operations (read more about CRUD here) and get your work done. That is pretty much what happens with a database.

Let’s talk about the data models. Data models is your application’s representation of the data it will be storing. This is extremely useful and essential when you are building your application. Data Models are nothing but classes whom’ s objects you will end up using to store data. You will use the full force of your years (and centuries if you believe in reincarnation) of training and superior thinking to design overtly complicated classes to store data. These are the data models.

Now, when it comes to having your data models interact with your database, you can take two routes. You can convert the data in the data model objects (which are, just to reaffirm, objects of your data model classes) into string, and then write them to the database yourself. This is one way of doing it. You do the reverse of that when you get data from the database and pour it into your database models.

Alternatively, you could use a ORM (Object Relational Model) system (about which you can read more about here) to help you do the two-way conversion of data model to database stuff. One such system would be the Entity Framework that I have already spent some time writing about, and you can find out about EF right here. Essentially ORM (in our case, the EF) is the middle guy who sits between your data model and database.

Hopefully, this post gave you an idea about who the three things – Data Models, Database and EF interact with each other.

Identity Roles and Identity Users

I posted about the asp dot net identity management system earlier (find it here). Two main components of this system that we will be using a lot in the web app we will be building soon (find it here), are identity roles and identity users.

Identity Roles are, as the name implies, are ‘roles’ that are assigned to a given user. It’s like how you have different types of responsibilities in any real life scenario. For instance, if you were to go to a restaurant, you will notice that different areas are reserved or forbidden. Perhaps the most obvious is the men and women’s restroom. Depending on your gender, you are not allowed to one or the other. Also, you will see that the staff are allowed to the back of the hotel, while you, the customer is not.

So, there are certain gates and entry restrictions that are placed all over the system, and the role assigned to you gives you access to one or the other entrance. In asp dot net identity management system (or library), you have the facility to assign different roles to different users. Roles can be removed, and roles can be added.

Roles are particularly useful when you are working with different user tiers. For instance, when a user registers on your web app, you might give them access to certain parts of the web app but still restrict access to views that allow interaction with data. Once the user has actually register, you could ‘promote’ that user to a basic user (who can edit some data) or an advanced user (who can edit all data). This is done by assigning different user roles.

The roles by themselves don’t do much. What does work is, how you can restrict access to different parts of the web app (which is actually restricting access to methods that return a view, but it is possible to restrict other aspects of the web app based on user roles). That means, there are two parts to any ‘restriction system’ that you would be building in a web app.

The first part would be coming up with a list of user roles. The second part is to apply those user roles to different parts of the web app. One goes with the other. Alone, they are incomplete and entirely useless.

Here is a small code snippet where you are removing an existing user role, and adding a new one.

            //remove existing role

            await UserManager.RemoveFromRoleAsync(tempuser.Id, temp[0]);

            var temp1 = await UserManager.GetRolesAsync(tempuser.Id);


            //add new role - CanSee

            var result_of_role_change = await UserManager.AddToRoleAsync(tempuser.Id, "canSee");

            var temp2 = await UserManager.GetRolesAsync(tempuser.Id);

Here is a small code snippet where you are restricting access, based on the user role.

    [Authorize(Roles = "canEdit")]

    public class AdminPanelController : Controller

The key thing is the ‘Authorize’ keyword. The authorize keyword will allow access to what follows (it could be a class or a method or anything else that works with the Authorize keyword) to whichever role is mentioned in the line. Further, it is possible to allow multiple user roles to have access to the same code block. It would look something like this.

    [Authorize(Roles = "canEdit,canSee")]

    public class SMSController : Controller

There you go then. You now know about user roles and users.