Skip to main content

Posts

Showing posts with the label View

EF warning while using Database first approach

Error 6002: The table/view 'AdventureWorks.dbo.BuildVersion' does not have a primary key defined. The key has been inferred and the definition was created as a read-only table/view. Explanation: The above warning is generated when you use Database first approach for Entity Framework model creation. Such warning appears due to entity key. Every Entity needs to have an entity key and when EF creates an entities, what it does is, it tries to find an primary key from the database and creates an entity key from that.  But it may be the case that few of the database objects doesn't have primary key defined. In that case, EF tries to infer a key based on your view or table's columns. So, here it becomes necessary to have at lease a non-null column in your database object.  It's just a warning, so nothing harmful here. But still if you need a solution to get rid of this warning, then it is posted by Hilmi Aric.

Simplest MVVM Ever - MVVM series 2 of n

Continuation to my previous article on  WHY and WHEN of MVVM , this time, I am going to tell something on how we can create a simple MVVM application with minimal complexities. I am writing this article for those, who just want to see quickly how MVVM works. It doesn't do anything fancy and uses some basic databindings and commanding stuff. This article will be helpful for all those who are looking for a quick example of how to hook the View to the ViewModel and how commands plays a role.  Today if you will surf internet, you will came across 1000s of articles discussing on what is MVVM and what are the major building blocks of it. So, I am going to repeat the same crazy thing again. But definitely, I'll brief you about major building blocks in layman, in order to make it easier to understand for beginners. Excited, eh ???  Layman introduction of building blocks    So, let's quickly start with three main layers of MVVM. Model  - Model contains the classes which ar

Why and When of MVVM - MVVM series 1 of n

Developing software is HARD. In fact, I would say, it's very HARD. Patterns and Architectural Structures help, but... it’s still hard. Like any other architectural structures, MVVM is also a structure with a set of guidelines and NOT a set of rules. In the past few months, I came across various forums and online discussions, where people often ask "Why should I use MVVM? It seems like it complicates things" and I realized that MVVM is very difficult to learn for beginners who have very little knowledge of design patterns and frameworks. As of today, if you will search MVVM in any of the search engines, you will get lot many articles written by the extremely knowledgeable through to the novices, and it is really hard to sort the wheat from the chaff. Apart from this, there are lot of resources which mention few points and miss out others, which may be very conflicting for those beginners as well as for some experienced programmers. I'm not going to call t

Starting with Prism - Part 2 of n

Background Continuing to my   Prism series 1 of n , in this series, I am going to talk about a few more interesting concepts like Modules and Views. Modules In this article, we will talk about how to take other views/logic and broken down into a small pieces called Modules and use them in your Prism application. We gonna start-up by talking about What a Module is, then registering Modules, loading Modules and then we will talk about how to initialize a Module. What is a Module? You can think Module as a building block for our Prism application. It is a package that contains all the functionalities and resources required for our application. Prism provides a support for run-time Module management in our application, in which each Module can be developed and tested independently. Prism application loads the Modules as and when they are required. Before moving forward, let’s have a look at how our application was architected inside Visual Studio prior to the concept of Module