jay's old blog

this blog will be deleted soon - please visit my new blog - https://thesanguinetechtrainer.com

Project TD - Day 59 update – Core Tech – Web api module and migrating to new blog



UPDATE 2!!!!

Alright, my new blog is now up and running. Find it here - https://thesanguinetechtrainer.com 


UPDATE!!!!

Okay. This is weird for me. For the last few days, BlogEngine.NET (the software that powers this blog) has been acting crazy. I have spent a good chunk of time troubleshooting (after all, I am myself a dot net developer and this thing was built using dot net, and I have come to a realization that, there is not fixing this. No one else is facing this issue.

I dont think it is a connection issue to the web server, because the blog itself is running just fine.

I dont think it is a database issue, because the blog does not use a database.

I thought there would be a easy way to export my blog to elsewhere, but nope. This blogengine software is not popular enough to merit that.

and, since I cannot create new posts (fortunately, existing posts can still be edited and updated) I am updating an existing post. I suppose I should be happy that at least this is working.

I am currently exploring both wordpress and medium as my next blogging software. I like the look of medium, so I will probably go with that. I still dont know how I will move all the stuff from this blog to the new medium blog, but right now, I need a place to write and publish. Or else, I will lose my mind. and fast, at that.

--------------------------------------------------------------------

When discussing the API engine, I put a flowchart in place that dictates how I would work on the different modules of the entire app ecosystem of project TD. Then, I further broke down the api engine into simpler modules, which I have discussed here. Here is that list, for reference.

  1. 1.       Build and Deploy an API
  2. 2.       POST and GET to the API
  3. 3.       PUSH and PULL from the API to the Data Service
  4. 4.       Google Maps API on Android, Web and iOS
  5. 5.       Facebook Login API on Android, Web and iOS

Obviously, I realized that some changes were needed, and here is the revised list of the simpler modules.

  1. 1.       Build and Deploy API (this includes the POST, GET, PUSH and PULL from the above list)
  2. 2.       Android app that works with the above API.
  3. 3.       iOS app that works with the above API.
  4. 4.       Web app that works with the above API.
  5. 5.       Google Maps API on Android, Web and iOS
  6. 6.       Facebook Login API on Android, Web and iOS

From the above list, 1 and 4, are completed. I mean, in software, there is no such thing as completed, but it is completed to acceptable levels. This blog, talks about 1 and 4, and I will move on to item 2/3/5/6 next.

As I have already decided, much of the back-end stuff, that is the API, is being built using .NET and that means, I get to use my favorite language c # for all of this. That much is done. I am using web api 2 technology for this. Since I don’t wish to manually create the tables for this service, I am using entity framework, version 6, to act as the agent between the api app and the database. For the database, I am using Microsoft SQL server, and for the hosted web app where the api would live, I am using an IIS server, powered by Microsoft technologies. All the server components are hosted on Microsoft Azure, and the cost, so far, (at the time of this writing) less than 500 rupees per month. Of course, this is a test server, and the load on it has been kept at extremely low levels. I am sure the actual cost when the full api ecosystem launches will be in triple or even quad digits.

While building this api, I ran into Knockout JS. I hadn’t used that one before. I also ran into attribute routing, which is a fun feature and I am surprised that it is a recent addition. I sort of assumed that it was always there. I also learnt about action names, but I think attribute routing sort of makes it redundant, but it is good to know it is there. Of course, the current api only communicates in text data, which might become a problem later when I wish to deal with multi media. However, from what I heard, the necessary modifications should not be a problem.

I am not currently satisfied with the way the web app works. It takes raw data, JSONifies the data on its own before consuming it. The web api does have components that return data in both raw format and JSON string format, so perhaps at some future time, I will build a web app that works with the JSON calls. For now, though, I will stick with the default web app built using Knockout JS.

The api is living on the cloud, and I have now completely abandoned the (soon to be retired) classic azure management portal. The new azure portal is sort of heavy on the system and it has this sliding interface which makes it difficult to work with. Especially as more azure components are loaded. However, it has all the new stuff, and for good or bad, Microsoft has been pushing the new portal for at least 3 years now. I guess, it is time for me to go with the change. I still don’t like it, but it is the future, so I am bending backwards for that.

As always, my tech guru, mika has been wonderfully helpful while building this. I want to thank him for his help, and hopefully, I will return the favor someday.

Alright, enough of the diary writing. You can find the two repos related to the above components, here and here. You can find the web app demoing the api, running at this link. Obviously, the repo has all the comments I can put and relevant links and stuff.

Alright, that is all for now.

Follow me on twitter, facebook and instagram for more updates. Thanks!

Supported Platforms – End Users



[Ongoing series of blog posts to inform potential developers, users and (hopefully investors) about this new app ecosystem I am architecting, designing, developing and deploying. More details at this page]

An ecosystem is worthless if people cannot use it on the platform of their choice. A few years ago (like say 2 years ago) deciding on the supporting end user platforms was tricky. The major platforms were windows desktop, windows touch enabled stuff – windows 8 and windows 10, then there was windows phone, the web browser on desktop, the web browser on mobiles, the web browser on tablets, and then of course android on phone, android on tablet and lastly, ios on phone and ios on tablets.

Phew! That is a lot of platforms. That would drive any developer crazy! It sure did drive me crazy.

Today, and during the year in which this blog post was written, I would say the tech revolution has reached its satisfactory conclusion. That’s good because, now things are simpler. As I continue my work on project TD, I must confess that life is a lot simpler now. With that knowledge, I know now that to reach to the widest audience, I only have to reach out to the following three platforms – Web Browser on desktop, android on phone, and iOS on phone.

Web Browser on desktop

At the end of the day, any machine with a keyboard plugged into it can run a web browser. I recently wrote about the appeal of web development. Web browsers have reached that maturity where they can support full-fledged applications. They also work well with touch enabled devices. A few years ago, I would have no choice but to build a traditional windows desktop application, the touch enabled and so called ‘modern’ or ‘metro’ apps for windows 8 / windows 10, and do the same for Mac and Linux.

Now, I don’t need to target any of these desktop platforms with native apps. The browser based app will take care of all this. Imagine the amount of effort I am able to save here. More importantly, we are now entering an era where a lot of people no longer think running applications in a browser is odd or weird. For someone who grew up in the 90s and early 00s, not using native desktop applications is odd. However, for those who grew up in the late 00s and onwards, using web app comes naturally. That means, having zero native apps will not hurt my ecosystem if it should go wide.

Android and iOS on phone

Intentionally, I have decided to leave out tablets entirely out of the picture. Perhaps, five years ago, we thoughts that tablets might go mainstream and even replace PCs and smartphones. Unfortunately, that did not happen, and I pretty much concluded my own observations in this post. Just this morning, I found out that the iPad version of the Instagram app is but a blown up iPhone app. This does not imply that a large company such as Instagram is lazy. On the contrary, it is a reflection of reality. Tablets are not a major platform and any time/money spent on it is not going to give returns.

Besides, phones have been getting bigger and have become ubiquitous. Thanks to improving infrastructure, it is not that expensive to download apps anymore. Phones also have better SD card support now, and most of them come with decent onboard storage as well. All in all, the mobile platforms have achieved a certain maturity which I should exploit.

Previously, I was of the opinion that I don’t wish to touch iOS. I assumed that developing for the apple platform can be pretty expensive. I also assumed that there are very few iPhones running around. However, I re-did some research, and see if perhaps the passage of time has changed the situation. I found out that at least some things have changed. A cheap Mac and a cheap iPhone can be obtained at prices slightly more than android development gear. The developer license continues to be expensive but that is a business cost. Further, I noticed that there are a small chunk of folks who are indeed using the older generation iPhones such as the 5c and 6, so perhaps there is indeed a user base to target.

All things considered, I decided that when it comes to mobile, I should target both android and iOS.

While I am writing about this, I must also mention the state of mobile optimization of the web apps, which are anyway being developed. I would say no. I am not going to go out of my way to optimize the above mentioned web apps to work on the small screen. Folks who want to use the site on their mobile browser should simply install the available mobile apps. Either that or live with poorly optimized web app. That, I am afraid, would be there choice.

Follow me on twitter, facebook and instagram for more updates. Thanks!

The Appeal and Non-Appeal Of Becoming A Web Developer



One of the many nice things about being a trainer is that I get to understand what is happening with folks, because when certain technologies are demanded, I get enquiries about stuff they wish to learn. That, indirectly, ties into what are the technologies being used. Over the last few months, the number of enquiries related to building apps that run within a web, in other words, web apps, are picking up speed. I must have dealt with at least a dozen students who asked for some work of web development training which involved either dot net, or one of the many Javascript libraries or a combination of both.

That makes me ask a question, one that gets asked a lot by students, why become a web developer? Alternatively, the question also implies, why not become a web developer? I will try to explain the situation to the best of my ability.

First up, web development is going to only increase in relevance as time grows. That is tied to the growth of mobile devices. Come to think of it, mobile devices are like everywhere now. At the same time, larger screen devices aren’t going anywhere. I use mobile devices, tablets, desktop PC and laptops with varying time spent, to get my work done and earn a living. A lot of times, I am using some variation of the same service to get work done.

That is where web apps become important. The appeal of web apps is that they run using the rules established for web browsers. That thing about web browsers is that they have a web engine, which in turn can work with these rules and regulations (or technology framework or web platform or…well, there are just so many words) and get things to work. This means, as long as this ‘web engine’ is running, the web app would run. This is where all those ‘hybrid’ apps and development tools become suddenly relevant. Hybrid apps are those that are (usually, because the web is such a stickler for using all kind of crazy words without standardizing it first) build using web technologies (HTML, CSS and many many Javascript libraries) and then deployed as apps. You could, technically, build a code, that can then run on the browser, android, iOS platforms with minimal changes.

This is where the opportunity to become a web developer arises. Let’s talk about the good stuff first. Unlike say, android development or windows development or iOS development, the tools needed to learn web development are pretty simple. An old laptop that costs less than rupees 10000 can be used (with some tradeoffs) to learn essential web development. That’s kind of neat isn’t it? When I started windows phone development, I spent a fortune (Windows Pro license, windows phone, a PC that can run the emulator, the developer license) to actually start learning the whole thing.

With web development, the costs of actual development are low. Along with this, the actual time it takes to learn web development is also on the lower side. The bedrocks of web development – HTML, CSS and JavaScript – are quite easy to become familiar with. A decent student, with enough dedication can become familiar enough to write basic apps in a matter of months. Becoming an expert is another story altogether.

With the mobile devices becoming truly ever prevalent and now in everybody and their mother’s hands, there is dearth of work. That means, even decent skills is enough to land some kind of employment. This is all the good stuff.

The two bad stuff, can get pretty sad for everybody involved. There is such a thing called platform diversity. You know how there are so many versions of android that plays havoc with android developers? You know how game developers complain about developing for windows, when compared to building for a Xbox One? Again, diversity of platform is the problem. Now expand that to include the web engine which should run on everything from PCs to mobiles to tablets to mobile devices. Then, there are so many operating systems. Even the same browser will exhibit different behavior on different platforms. Then, screen resolutions that vary like crazy. This is what is called a messed up kitchen, and this is also where you look at things and go, ‘This is Heavy doc!’!!!

As if this is not enough, there must be dozens of JavaScript libraries out there. Every company wants people to use their own library. Facebook wants people to use React JS. Microsoft wants people to use TypeScript. Then there is jQuery, which has its own agenda. Don’t forget the visual enhancements provided by Bootstrap which also does some script work. There is also good old JavaScript which does a lot of things. Then, there are modules that are in turn used by these libraries, and many of them are self-tested with or without update support.

When I think about all this, all I can think of is a house of cards. It gets scary, and that is why developers should be scared. Or at least worried. There is just too much to keep track of, and more importantly, you never when something (like a module, or a library) will suddenly become not available, and then your app simply stops working! This happens with any software, but at least with a windows environment or an android, there is a big company in charge, which can usually provide some kind of a normalcy by fixing things.

With web, everybody owns some piece of something. In other words, when things go bad, nobody will take responsibility or will not be required take ownership. It can get crazy, but the web is a crazy world.

The second problem is an offshoot of the lower learning costs that I talked about. When costs are low, the barriers of entry also reduce. That means, more people will try and become part of the party. When there are too many people standing in queue to join a party (that is looking for employment) the party organizers (in this case organizers) have more choice. More choice means less pay. This also means less security when it comes to jobs. Given the ever changing nature of the web, folks who just finished learning something must be ready to learn again, or else, someone younger, cheaper and equipped with the latest skills will replace them. Heck, automation (the irony being that they were build using these web languages) itself will begin replacing developers!

If you are looking to enter this crazy world of web development, the key is to look at how talented or desperate you are. If it is the former, you will make a killing. If it is the latter, god help you.

Follow me on twitter, facebook and instagram for more updates. Thanks!

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 - https://bitbucket.org/studynildana/demo_asp_dot_net_1

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

        [Required]

        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)

        {

            modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();

        }

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.

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 - https://bitbucket.org/studynildana/demo_asp_dot_net_1

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.

Identity Management in asp dot net

There are many reasons why web sites are now called web apps. One of those, would be, the fact that they provide at least some kind of customization based on the simple fact of a user being logged in. For instance, a website that simple shows news would be a ‘web site’. However, a web site that allows a user to login, and hence customize the news that is displayed, based on the logged in user’s preferences would become a web app.

That brings us to another essential facet of asp dot net, the identity management system. Before we understand the identity management system provided by asp, perhaps we should figure out what makes an ‘identity management system’. At its most basic form, this system should provide

·         An interface that allows new users to register.

·         An interface that allows registered users to login.

·         A system that allows these users to be assigned different roles. These roles will then be used to provide differentiated access to different parts of the web app.

·         The system should also seamlessly integrate with the database context, hiding the database related operates related to these users as well as their roles.

When building any system that operates with multiple users, the developer is tasked with building a user management system which at least offers the above. Now, it is fairly obvious that user management is a huge responsibility. One can read endless stories on the internet about how one company or the other company has been hacked and user data stolen. A discussion about the consequences of losing customer data for a company is beyond the scope of this blog post, but it is extremely bad. So, building a user management system is almost as complicated as building the rest of actual web app.

That is where asp dot net’s identity management system comes into the picture. It provides an out of the box solution that can be readily added to the web app. It provides all the essentials that I have described above, and much more (like integration with social logins such as facebook and twitter, OTP and email based password reset).

The best way to include identity management in your web app would be to ‘enable authentication’ when creating a new project. If you have already created the project, you can add the identity library manually through the package manager, but I really think that identity management should be part of your project from the project creation time. So, if you forgot to include authentication, it would simply be better to create a new project, after having looked at the mirror to realize what a moron you are.

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.

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.