WPF 3D with Helix Toolkit

Helix Toolkit builds on the 3-D functionality in Windows Presentation Foundation (WPF).  This toolkit provides a higher level API for working with 3D in WPF, via a collection of controls and helper classes.

Using the Package Manager Console To install HelixToolkit.Wpf, run the following command in the Package Manager Console.

PM> Install-Package HelixToolkit.Wpf

Using the Nuget UI

To find HelixToolkit in NuGet, follow these steps:
1. Open your project in Visual Studio.
2. Right click on the References folder and select “Manage Nuget Packages…” from the context menu.
3. In the “Manage Nuget Packages” dialog, select “Online” on the right.
4. In the search field, enter “HelixToolkit”.
5. Select the HelixToolkit.Wpf package and press the Install button.

Creating a 3D view

The HelixViewport3D is the object that will contain our 3D scene. This is a WPF control allowing for imperative or declarative coding. Lets create a HelixViewport3D object using C#.

private void Create3DViewPort() { var hVp3D = new HelixViewport3D(); }

Using XAML object creation would look like this.

<code>&lt;Window x:Class="GettingStartedDemo.MainWindow" 
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:h="http://helix-toolkit.org/wpf"
        Title="Getting Started Demo" Height="480" Width="640"&gt;

     &lt;h:HelixViewport3D &gt;
     &lt;/h:HelixViewport3D&gt;

 &lt;/Window&gt;
</code>

This gives us a 3D space in which to setup our scene and work with 3D objects.

Adding lights

Next we need to add lighting to the HelixViewport3D. Without lighting, objects in the view-port scene will not be visible.

In C#:

<code>private void Create3DViewPort()
{
    var hVp3D = new HelixViewport3D();
    var lights = new DefaultLights();
    hVp3D.Children.Add(lights);
} 
</code>

In XAML:

<code>&lt;h:HelixViewport3D &gt;
     &lt;h:DefaultLights/&gt;
 &lt;/h:HelixViewport3D&gt;
</code>

Adding 3D content

Now that we have light and a view-port we can add a 3D object. Helix Toolkit comes with several 3D objects such as a box, tube, helix, pipe, and of course a teapot. Let’s add the teapot to the view-port.

In C#:

<code> private void Create3DViewPort()
 {
     var hVp3D = new HelixViewport3D();
     var lights = new DefaultLights();
     var teaPot = new Teapot();
     hVp3D.Children.Add(lights);
     hVp3D.Children.Add(teaPot);
  } 
</code>

In XAML:

<code> &lt;h:HelixViewport3D &gt;
      &lt;h:DefaultLights/&gt;
      &lt;h:Teapot/&gt;
 &lt;/h:HelixViewport3D&gt;
</code>

Complete Getting Started Example Code

In C#:

<code>public partial class MainWindow
{
    public MainWindow()
    {
        this.InitializeComponent();
        Create3DViewPort();
    }

    private void Create3DViewPort()
    {
        var hVp3D = new HelixViewport3D();
        var lights = new DefaultLights();
        var teaPot = new Teapot();
        hVp3D.Children.Add(lights);
        hVp3D.Children.Add(teaPot);
        this.AddChild(hVp3D);
    }
}
</code>

In XAML:

<code>&lt;Window x:Class="GettingStartedDemo.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:h="http://helix-toolkit.org/wpf"
        Title="Getting Started Demo" Height="480" Width="640"&gt;

    &lt;h:HelixViewport3D &gt;
        &lt;h:DefaultLights/&gt;
        &lt;h:Teapot/&gt;
    &lt;/h:HelixViewport3D&gt;</code>

Full-Stack MVC Application Development with AngularJS

These days, developers are interested to use AngularJS and ASP.NET MVC (wiring MVC and AngularJS). So in this post we will learn how to combine the best of both worlds and use the goodness of AngularJS in ASP.NET MVC. 

To start, let’s create ASP.NET MVC application and right click on the MVC project. From the context menu, click on Manage Nuget Package. Search for the AngularJS package and install into the project.

After successfully adding the AnngularJS library, you can find those files inside the Scripts folders.

Reference of AngularJS library

You have two options to add an AngularJS library reference in the project: MVC minification and bundling or by adding AngularJS in the Script section of an individual view. If you use bundling, then AngularJS will be available in the whole project. However you have the option to use AngularJS on a particular view as well.

Let’s say you want to use AngularJS on a particular view (Index.cshtml) of the Home controller. First you need to refer to the AngularJS library inside the scripts section as shown below:

@section scripts{

    <script src=”~/Scripts/angular.js”>script>

}

Next, apply the ng-app directive and any other required directives on the HTML element as shown below:

<div ng-app=”” class=”row”>

     <input type=”text” ng-model=”name” />

     {{name}}

div>

When you run the application you will find AngularJS is up and running in the Index view. In this approach you will not be able to use AngularJS on the other views because the AngularJS library is only referenced in the Index view.

You may have a requirement to use AngularJS in the whole MVC application. In this case, it’s better to use bundling and minification of MVC and all the AngularJS libraries at the layout level. To do this, open BundleConfig.cs from the App_Start folder and add a bundle for the AngularJS library as shown below:

  public static void RegisterBundles(BundleCollection bundles)

        {

            bundles.Add(new ScriptBundle(“~/bundles/angular”).Include(

                        “~/Scripts/angular.js”));

 

After adding the bundle in the BundleConfig file, next you need to add the AngularJS bundle in the _Layout.cshtml as listed below:

<head>

    <meta charset=”utf-8″ />

    <meta name=”viewport” content=”width=device-width, initial-scale=1.0″>

    <title>@ViewBag.Title – My ASP.NET Applicationtitle>

    @Styles.Render(“~/Content/css”)

    @Scripts.Render(“~/bundles/modernizr”)

    @Scripts.Render(“~/bundles/angular”)

    @Scripts.Render(“~/bundles/jquery”)

    @Scripts.Render(“~/bundles/bootstrap”)

    @RenderSection(“scripts”, required: false)

head>

After creating an AngularJS bundle and referring to it in _Layout.cshtml, you should be able to use AngularJS in the entire application.

 

Full-Stack MVC Application with Redux

This post covers the end-to-end process (wiring MVC and React) of creating a brand new ASP.NET MVC website and adding a React component in it. We will start from scratch and end with a fully functioning component.

We can use .NET Framework, but you can instead use .NET Core if you want to be able to run your site on Linux or Mac OS. Currently .NET Core is missing some of the functionality provided by .NET Framework, so it is recommended to use .NET Framework unless you have a reason to use .NET Core specifically (eg. cross-platform support).

Start by creating a new ASP.NET Core MVC project:

  1. File → New → Project
  2. Ensure “.NET Framework 4.6” is selected in the dropdown list at the top
  3. Go to Templates → Visual C# → Web and select the “ASP.NET Core Web Application (.NET Framework)” template. 

We need to install ReactJS.NET to the newly-created project. This is accomplished using NuGet, a package manager for .NET. Right-click on your project in the Solution Explorer and select “Manage NuGet Packages”. Click the “Browse” tab, search for “React.AspNet”, and install the React.AspNet package.

We also need to modify the Startup.cs file to initialize ReactJS.NET. Open Startup.cs and perform the following changes:

At the top of the file, add:

<code class="csharp language-csharp" data-lang="csharp"><span class="k">using</span> <span class="nn">Microsoft.AspNetCore.Http</span><span class="p">;</span>
<span class="k">using</span> <span class="nn">React.AspNet</span><span class="p">;</span>
</code>

Directly above:

<code class="csharp language-csharp" data-lang="csharp"><span class="c1">// Add framework services.</span>
<span class="n">services</span><span class="p">.</span><span class="n">AddMvc</span><span class="p">();</span>
</code>

Add:

<code class="csharp language-csharp" data-lang="csharp"><span class="n">services</span><span class="p">.</span><span class="n">AddSingleton</span><span class="p">&lt;</span><span class="n">IHttpContextAccessor</span><span class="p">,</span> <span class="n">HttpContextAccessor</span><span class="p">&gt;();</span>
<span class="n">services</span><span class="p">.</span><span class="n">AddReact</span><span class="p">();</span>
</code>

Directly above:

<code class="csharp language-csharp" data-lang="csharp"><span class="n">app</span><span class="p">.</span><span class="n">UseStaticFiles</span><span class="p">();</span>
</code>

Add:

<code class="csharp language-csharp" data-lang="csharp"><span class="c1">// Initialise ReactJS.NET. Must be before static files.</span>
<span class="n">app</span><span class="p">.</span><span class="n">UseReact</span><span class="p">(</span><span class="n">config</span> <span class="p">=&gt;</span>
<span class="p">{</span>
  <span class="c1">// If you want to use server-side rendering of React components,</span>
  <span class="c1">// add all the necessary JavaScript files here. This includes</span>
  <span class="c1">// your components as well as all of their dependencies.</span>
  <span class="c1">// See http://reactjs.net/ for more information. Example:</span>
  <span class="c1">//config</span>
  <span class="c1">//  .AddScript("~/Scripts/First.jsx")</span>
  <span class="c1">//  .AddScript("~/Scripts/Second.jsx");</span>

  <span class="c1">// If you use an external build too (for example, Babel, Webpack,</span>
  <span class="c1">// Browserify or Gulp), you can improve performance by disabling</span>
  <span class="c1">// ReactJS.NET's version of Babel and loading the pre-transpiled</span>
  <span class="c1">// scripts. Example:</span>
  <span class="c1">//config</span>
  <span class="c1">//  .SetLoadBabel(false)</span>
  <span class="c1">//  .AddScriptWithoutTransform("~/Scripts/bundle.server.js");</span>
<span class="p">});</span>
</code>

Finally, add this to Views\_ViewImports.cshtml:

<code class="csharp language-csharp" data-lang="csharp"><span class="n">@using</span> <span class="n">React</span><span class="p">.</span><span class="n">AspNet</span></code>

 

ASP.NET MVC and Redux

When we at Spoil decided to roll out our mobile app, one of the first decisions we had to make was: what language do we use? After some deliberation, the decision was made: React-Native it was going to be. Learning a new “language” or framework isn’t a huge issue. 

React-Native and Redux?

As soon as you start learning about react-native (or react), you start to understand state vs props, you know what componentDidMount does and you even understand how to properly create your components so they are re-usable. Now all of a sudden you found yourself talking about stores, reducer compositions, actions and mapping state to props.

Some Analogies

If you are coming from an MVC (or MVVC) world, you are used to models, views and controllers. However in Redux we are dealing with actions, reducers, stores and components. Trying to “translate” MVC to Redux is tricky but here is how I would do it:

Actions = Controller. Think of your actions as the controller. Whenever you want something to happen in your app (i.e. load some data, change a isLoading flag from true to false…) you will have to dispatch an action. Just like in MVC where you would have to call a controller endpoint.

Reducer = Model. Sort of. Your reducers will be in charge of holding the current state of your application (i.e. user info, information loaded from the api, items you want to display…). It will also be the part that decides what to do when an action is called. While in MVC you might have a model with the method setName(), with Redux you would have a reducer handle an action to set the name in the state.

Stores = ???. The store is Redux specific and doesn’t really have an equivalent in MVC. Not to worry though. This part is taken care off behind the scenes. The store is like a container for the state that aggregates all of the reducers. It has a method to the get the current state, and exposes ways to subscribe to the state changes (using the “connect()” method). This is what will allow you to call actions and pass them in as props to your components.

Components = Views. Components are kind of like your smart views. They display the information that they get from the state. I recommend splitting up your components into two parts. One just for the presentational part (dumb components) and one to handle all of the actions and state changes (smart components).

Moving From MVC Thinking to Redux Thinking

One of the main differences between MVC and Redux is that, while in MVC data can flow in a bidirectional manner, in Redux it strictly moves in one direction.

With Redux things work a little differently. Let’s say you have a component and you want to do something when a button gets pressed. Where do you start? 

  1. Define your Action
  2. Define your Reducer
  3. Define the Actions as a Prop in your Component
  4. Wire it up in your View

 

Web API Pros and Cons

With the new changes to the Web API, there has been a lot of discussion of where the new Web API technology fits in the ASP.NET Web stack. There are a lot of choices to build HTTP based applications available now on the stack – we’ve come a long way from when WebForms and Http Handlers/Modules where the only real options. Today we have WebForms, MVC, ASP.NET Web Pages, ASP.NET AJAX, WCF REST and now Web API as well as the core ASP.NET runtime to choose to build HTTP content with.

Web API definitely squarely addresses the ‘API’ aspect – building consumable services – rather than HTML content, but even to that end there are a lot of choices you have today. So where does Web API fit, and when doesn’t it?

 

What is a Web API?

HTTP ‘APIs’ are becoming increasingly more important with the rise of the many devices in use today. Most mobile devices like phones and tablets run Apps that are using data retrieved from the Web over HTTP. Desktop applications are also moving in this direction with more and more online content and syncing moving into even traditional desktop applications. The pending Windows 8 release promises an app like platform for both the desktop and other devices, that also emphasizes consuming data from the Cloud.

Likewise many Web browser hosted applications these days are relying on rich client functionality to create and manipulate the browser user interface, using AJAX rather than server generated HTML data to load up the user interface with data.

These mobile or rich Web applications use their HTTP connection to return data rather than HTML markup in the form of JSON or XML typically. But an API can also serve other kinds of data, like images or other binary files, or even text data and HTML (although that’s less common). A Web API is what feeds rich applications with data.

ASP.NET Web API aims to service this particular segment of Web development by providing easy semantics to route and handle incoming requests and an easy to use platform to serve HTTP data in just about any content format you choose to create and serve from the server.

 The .NET stack already includes a number of technologies that provide the ability to create HTTP service back ends, and it has done so since the very beginnings of the .NET platform. From raw HTTP Handlers and Modules in the core ASP.NET runtime, to high level platforms like ASP.NET MVC, Web Forms, ASP.NET AJAX and the WCF REST engine (which technically is not ASP.NET, but can integrate with it), you’ve always been able to handle just about any kind of HTTP request and response with ASP.NET. The beauty of the raw ASP.NET platform is that it provides you everything you need to build just about any type of HTTP application you can dream up from low level APIs/custom engines to high level HTML generation engine. ASP.NET as a core platform clearly has stood the test of time 10+ years later and all other frameworks like Web API are built on top of this ASP.NET core.

However, although it’s possible to create Web APIs / Services using any of the existing out of box .NET technologies, none of them have been a really nice fit for building arbitrary HTTP based APIs. Sure, you can use an HttpHandler to create just about anything, but you have to build a lot of plumbing to build something more complex like a comprehensive API that serves a variety of requests, handles multiple output formats and can easily pass data up to the server in a variety of ways. Likewise you can use ASP.NET MVC to handle routing and creating content in various formats fairly easily, but it doesn’t provide a great way to automatically negotiate content types and serve various content formats directly (it’s possible to do with some plumbing code of your own but not built in). Prior to Web API, Microsoft’s main push for HTTP services has been WCF REST, which was always an awkward technology that had a severe personality conflict, not being clear on whether it wanted to be part of WCF or purely a separate technology. In the end it didn’t do either WCF compatibility or WCF agnostic pure HTTP operation very well, which made for a very developer-unfriendly environment.

ASP.NET Web API differentiates itself from the previous Microsoft in-box HTTP service solutions in that it was built from the ground up around the HTTP protocol and its messaging semantics. Unlike WCF REST or ASP.NET AJAX with ASMX, it’s a brand new platform rather than bolted on technology that is supposed to work in the context of an existing framework. The strength of the new ASP.NET Web API is that it combines the best features of the platforms that came before it, to provide a comprehensive and very usable HTTP platform. Because it’s based on ASP.NET and borrows a lot of concepts from ASP.NET MVC, Web API should be immediately familiar and comfortable to most ASP.NET developers.

Here are some of the features that Web API provides:

  • Strong Support for URL Routing to produce clean URLs using familiar MVC style routing semantics
  • Content Negotiation based on Accept headers for request and response serialization
  • Support for a host of supported output formats including JSON, XML, ATOM
  • Strong default support for REST semantics but they are optional
  • Easily extensible Formatter support to add new input/output types
  • Deep support for more advanced HTTP features via HttpResponseMessage and HttpRequestMessage
    classes and strongly typed Enums to describe many HTTP operations
  • Convention based design that drives you into doing the right thing for HTTP Services
  • Very extensible, based on MVC like extensibility model of Formatters and Filters
  • Self-hostable in non-Web applications 
  • Testable using testing concepts similar to MVC

Web API is meant to handle any kind of HTTP input and produce output and status codes using the full spectrum of HTTP functionality available in a straight forward and flexible manner.

Looking at the list above you can see that a lot of functionality is very similar to ASP.NET MVC, so many ASP.NET developers should feel quite comfortable with the concepts of Web API. The Routing and core infrastructure of Web API are very similar to how MVC works providing many of the benefits of MVC, but with focus on HTTP access and manipulation in Controller methods rather than HTML generation in MVC.

There’s much improved support for content negotiation based on HTTP Accept headers with the framework capable of detecting automatically what content the client is sending and requesting and serving the appropriate data format in return. This seems like such a little and obvious thing, but it’s really important. Today’s service backends often are used by multiple clients/applications and being able to choose the right data format for what fits best for the client is very important.

While previous solutions were able to accomplish this using a variety of mixed features of WCF and ASP.NET, Web API combines all this functionality into a single robust server side HTTP framework that intrinsically understands the HTTP semantics and subtly drives you in the right direction for most operations. And when you need to customize or do something that is not built in, there are lots of hooks and overrides for most behaviors, and even many low level hook points that allow you to plug in custom functionality with relatively little effort.

If your primary focus of an application or even a part of an application is some sort of API then Web API makes great sense.

HTTP Services
If you’re building a comprehensive HTTP API that is to be consumed over the Web, Web API is a perfect fit. You can isolate the logic in Web API and build your application as a service breaking out the logic into controllers as needed. Because the primary interface is the service there’s no confusion of what should go where (MVC or API). Perfect fit.

Primary AJAX Backends
If you’re building rich client Web applications that are relying heavily on AJAX callbacks to serve its data, Web API is also a slam dunk. Again because much if not most of the business logic will probably end up in your Web API service logic, there’s no confusion over where logic should go and there’s no duplication. In Single Page Applications (SPA), typically there’s very little HTML based logic served other than bringing up a shell UI and then filling the data from the server with AJAX which means the business logic required for data retrieval and data acceptance and validation too lives in the Web API. Perfect fit.

Generic HTTP Endpoints
Another good fit are generic HTTP endpoints that to serve data or handle ‘utility’ type functionality in typical Web applications. If you need to implement an image server, or an upload handler in the past I’d implement that as an HTTP handler. With Web API you now have a well defined place where you can implement these types of generic ‘services’ in a location that can easily add endpoints (via Controller methods) or separated out as more full featured APIs. Granted this could be done with MVC as well, but Web API seems a clearer and more well defined place to store generic application services. This is one thing I used to do a lot of in my own libraries and Web API addresses this nicely. Great fit.

 

Mixed HTML and AJAX Applications: Not a clear Choice 

For all the commonality that Web API and MVC share they are fundamentally different platforms that are independent of each other. A lot of people have asked when does it make sense to use MVC vs. Web API when you’re dealing with typical Web application that creates HTML and also uses AJAX functionality for rich functionality. While it’s easy to say that all ‘service’/AJAX logic should go into a Web API and all HTML related generation into MVC, that can often result in a lot of code duplication. Also MVC supports JSON and XML result data fairly easily as well so there’s some confusion where that ‘trigger point’ is of when you should switch to Web API vs. just implementing functionality as part of MVC controllers.

Ultimately there’s a tradeoff between isolation of functionality and duplication. A good rule of thumb I think works is that if a large chunk of the application’s functionality serves data Web API is a good choice, but if you have a couple of small AJAX requests to serve data to a grid or autocomplete box it’d be overkill to separate out that logic into a separate Web API controller. Web API does add overhead to your application (it’s yet another framework that sits on top of core ASP.NET) so it should be worth it

Keep in mind that MVC can generate HTML and JSON/XML and just about any other content easily and that functionality is not going away, so just because you Web API is there it doesn’t mean you have to use it. Web API is not a full replacement for MVC obviously either since there’s not the same level of support to feed HTML from Web API controllers (although you can host a RazorEngine easily enough if you really want to go that route) so if you’re HTML is part of your API or application in general MVC is still a better choice either alone or in combination with Web API.

 

Some Issues about Web API

Web API is similar to MVC but not the Same

Although Web API looks a lot like MVC it’s not the same and some common functionality of MVC behaves differently in Web API. For example, the way single POST variables are handled is different than MVC and doesn’t lend itself particularly well to some AJAX scenarios with POST data.

Code Duplication

If you build an MVC application that also exposes a Web API it’s quite likely that you end up duplicating a bunch of code and – potentially – infrastructure. You may have to create authentication logic both for an HTML application and for the Web API which might need something different altogether. More often than not though the same logic is used, and there’s no easy way to share. If you implement an MVC ActionFilter and you want that same functionality in your Web API you’ll end up creating the filter twice.

 

Conclusion

Web API is a great new addition to the ASP.NET platform and it addresses a serious need for consolidation of a lot of half-baked HTTP service API technologies that came before it. Web API feels ‘right’, and hits the right combination of usability and flexibility at least for me and it’s a good fit for true API scenarios. However, just because a new platform is available it doesn’t mean that other tools or tech that came before it should be discarded or even upgraded to the new platform. There’s nothing wrong with continuing to use MVC controller methods to handle API tasks if that’s what your app is running now – there’s very little to be gained by upgrading to Web API just because. But going forward Web API clearly is the way to go, when building HTTP data interfaces.

Web API 2.0

ASP.NET Web API 2 has been released with a number of new exciting features:
 

1. Attribute Routing

Along with convention-based routing, Web API 2 now supports attribute routing as well.

In case of convention-based routing, we can define multiple route templates. When a request comes, it will be matched against already defined route templates, and forwarded to specific controller action according to matched template.

You can see the following default route template in routing table for Web API:

This routing approach has benefits that all routing templates are defined at one common location but for certain URI patterns, it really becomes difficult to support (like nested routing on same controller).

With ASP.NET Web API 2, we can easily support above mentioned URI pattern and others as well. Following shows an example of a URI pattern with attribute routing. URI Pattern –> books/1/authors


2. CORS – Cross Origin Resource Sharing

Normally, browsers don’t allow making cross-domain calls due to same-origin policy and we know that. So, what exactly is CORS (Cross Origin Resource Sharing)?

CORS is a mechanism that allows a web page to make an AJAX call to a domain other than the domain which actually rendered that specific web page. CORS is compliant with W3C standards and now ASP.NET Web API has support for it in version 2.

 

3. OWIN (Open Web Interface for .NET) self hosting

ASP.NET Web API 2 comes with a new self hosting package i.e. Microsoft.AspNet.WebApi. OwinSelfHost.   According to http://owin.org/

OWIN defines a standard interface between .NET web servers and web applications. The goal of the OWIN interface is to decouple server and application, encourage the development of simple modules for .NET web development, and, by being an open standard, stimulate the open source ecosystem of .NET web development tools.

So, according to above description, OWIN is an ideal option for self hosting a web application in a process other than IIS process.

There are a number of OWIN implementations like Giacomo, Kayak, Firefly etc. available (some may be partial or outdated) but Katana is the recommended one for Microsoft servers and Web API frameworks.

 

4. IHttpActionResult

Along with the existing two approaches of creating response from controller action, ASP.NET Web API 2 now supports another way of doing the same. IHttpResponseMessage is basically an interface which acts as a factory for HttpResponseMessage. It’s very powerful because it extensify web api. Using this approach we can compose any specific type of response.

 

5. Web API OData

The Open Data Protocol (OData) is actually a web protocol for querying and updating data. ASP.NET Web API 2 has added support for $expand, $select, and $value options for OData. By using these options, we can control the representation that is returned from the server.

  • $expand: Normally, response doesn’t include related entities if we query an OData collection. By using $expand, we can get related entities inline in response.
  • $select: It’s used if we wanted to include subset of properties in response instead of all.
  • $value: It allows to return raw value of the property instead returning in OData format.

 

 

 

Why Entity Framework 7?

Upgrade to EF7 

If you’re currently on EF6, you might jump to the conclusion that you should upgrade to EF7 as soon as it hits the streets, but should we move to EF7? for some folks the answer will be, “Maybe never.” That’s right. There are certain features and development approaches that are being deprecated. The most notable is support for EDMX-based development, which is sometimes referred to as “model first” or “designer based.” Going forward, EF7 and beyond will only support code-based modeling, also known as “code first,” but which also includes reverse engineering code first entities from an existing database.

So if you have heavy investment in EDMX-based models, then you might want to completely rule out upgrading beyond EF6. After all, EF6 is mature, feature-rich, stable and performant. Because of that, it’s not going away anytime soon, and the team is continuing to fix defects and add minor features. It also might take a while for providers other than SQL Server, such as Oracle, to release versions that are compatible with EF7.

EF7 Applications

  • ASP.NET 5: This will be a “cloud-friendly” version of ASP.NET that allows you to target a stripped down and NuGet deployable version of the CLR, called .NET CLR Core. EF7 was re-written from the ground up mainly to support this scenario. Besides, EF6 won’t support CoreCLR and you’ll have to use EF7 if you want to take advantage of the version of .NET that targets the cloud.
  • Apps that use EF with code-based modeling (aka Code First), where you don’t use features not yet supported by EF7 . The bonus here is that EF7 is deployed as a set of Portable Class Libraries that can run on .NET 4.5.1, Windows 8.1 and Windows Phone 8.1 (and by extension on iOS and Android via Xamarin). There is also an In-Memory provider that is useful for testing scenarios.
  • You want to target non-relational data stores, such as Azure Table Storage or Redis, and you’re willing to wait for those providers to be written. In order to focus on rounding out the basic feature set and supporting ASP.NET 5, the EF team froze their work on non-relational providers. They will eventually come along, but you may need to wait a little while.
  • You want to target a local SQLite database on a mobile device and you’re willing to wait some more. Just like non-relational stores, development on the SQLite provider is being postponed until after the initial release and inclusion of basic features.

Beyond the support for ASP.NET 5, non-relational stores, and mobile platforms, most of what’s cool about EF7 is under the covers. It’s being written in the same modular fashion that makes ASP.NET 5 a compelling story. The idea behind it is to cut loose from the bonds of its legacy to provide a product where you can pick and choose just the components you need and can more easily insert custom extensions and configurations into the pipeline. This is what makes it cloud-friendly, because it reduces the application footprint in an environment where memory and processing resources are pay-as-you-go. And just like ASP.NET 5, EF7 has been designed so that dependency injection and testability are first-class citizens.

Starting from scratch has enabled the EF team to add features which were difficult to plug in while tethered to the old code base. These include batch updates (sending multiple statements to the database in a single round trip) and the ability to define unique constraints on entities besides the primary key. EF7 will also allow parts of queries to be executed locally and for providers to handle queries which produce multiple result sets.

Entity Framework 7 (EF7)

EF7 is more powerful and has significant changes over Entity Framework 6.x. Entity Framework 7 will give you familiar developer experience to previous versions of EF, the user can still work with DbContext, DbSet, etc.

EF7 is much more lightweight than previous versions and is built from the ground up to work great in the cloud (using ASP.NET vNext) on devices (i.e. in universal Windows apps) as well as in traditional .NET scenarios.

Important features of Entity Framework 7:

Lightweight and extensible

Instead of use existing Entity Framework 6 APIs, Team decide to start developing from the scratch. You can use only that extensions which are useful to your project. The pattern and concept remain same to use Entity Framework. You can use DbContext/DbSet same way as you are currently using. The advantage of extensible is you can replace and extend it.

New Platforms

EF is most popular ORM that currently includes applications built with technologies such as WPF, WinForms and ASP.NET. After looking at future Microsoft has decided to support remaining platforms where .NET development is common. This includes Windows Store, Windows Phone and the Cloud Optimized .NET.

New Data Stores

Entity Framework was clearly tied with relational data stores. Now onward EF provide great support to non relational data stores also. Relational & non Relational, like Azure table storage.

Optimized Query generation

Based on people’s higher request on EF uservoice “Improved SQL Generation“, Diego Vega (Engineering Manager, Entity Framework) responded positively and start working on this feature. On next or may be final release they will include this feature. EF7 will generate much simpler SQL queries than EF6 for the most common scenarios.

Code first only

Finally Microsoft Team retired EDMX in Entity Framework 7. You can read Rowan Miller’s article EF7 – What Does “Code First Only” really mean. If you still love edmx, you would love to read What about EDMX when EF7 arrives? written by Julie Lerman.

Batch Update

No longer need to use EF batch update utilities to perform batch operations because EF7 has inbuilt support for that. EF 7 no longer send individual command for every insert/update/delete statement. EF 7 will batch multiple statements in single round trip to the database.

Unique Constraints

EF 7 allows you to identify additional unique keys within your entities in addition to the primary key. You can then use these alternate keys as the target of foreign key relationships. A unique constraint is introduced for each alternate key in the model.

Azure API Service Architecture

The Azure App Service platform brings the best of what the Azure Cloud has to offer into one cohesive and flexible architecture. Azure App Service makes it easy to build enterprise systems leveraging both your own and third-party APIs.

Azure App Service brings together Web Applications, Mobile Applications, and powerful new Logic Apps, all of which communicate with Azure API Apps. There are many options to build these systems, to consume RESTful Web APIs and to automate client code generation which can significantly reduce the amount of manually written code. 

The new App Service supports the following application categories:

  • Web Apps – Azure Websites service is rechristened as Web Apps. This service provides a polyglot environment to host websites developed in .NET, Java, PHP, Node.js and Python. Web Apps gallery offers developers a one-click capability to install packages like WordPress, Joomla and Drupal. Web Apps can be configured for auto-scaling to dynamically scale-up or scale-out. Developers can configure continuous integration and deployment workflows with VSO, GitHub, TeamCity, Hudson or BitBucket. The service makes it easy to perform A/B testing to verify new code by selectively routing a fraction of live traffic.
  • Mobile Apps – Azure Mobile Services feature has become Mobile Apps within App Service. Mobile developers can take advantage of App Service to build native iOS, Android, and Windows apps or cross-platform Xamarin or Cordova (Phonegap) apps. The service supports hybrid capability to connect mobile applications with enterprise on-premises data. With the new SaaS API connectors, mobile developers can easily integrate their apps with popular 3rd party services such as Twitter, Salesforce and Twilio. Offline Sync and Push notifications are other key features of this service.
  • Logic Apps – Logic Apps allow developers to design workflows based on a series of steps that are triggered by an event. Developers can stitch multiple APIs and services as a part of the workflow without writing complex code. Existing templates provide a good starting point for developers to quickly design workflows. The connector marketplace acts as an exchange to publish and consume custom API Apps that can be used in Logic Apps. BizTalk Services are tightly integrated with Logic Apps to provide advanced integration scenarios.
  • API Apps – API Apps make it easy to develop, publish, manage, and monetize APIs. Developers can publish APIs written in ASP.NET, Java, PHP, Node.js or Python. Through simple access control, authentication can be built into APIs. Developers can share APIs with other teams within an organization, by using their own private organizational gallery of APIs or they can also be shared publicly for consumption by third party developers. Azure App Service can automatically build SDKs for a variety of languages including C#, Java, and Javascript, making APIs available to many platforms.

This consolidation turns Azure PaaS into a rich application platform. According to Microsoft, App Service delivers a fully managed and secure infrastructure for developers to build cloud-first and mobile-first applications.

OData Pros and Cons

OData is the Open Data Protocol. It is an open web protocol started by Microsoft to expose data using existing web technologies. This is based on Representational State Transfer (REST) full architecture. HTTP, AtomPub (similar to RSS, but specifically introduced special XML format for OData), JSON are all supported.
Here, the URL is the primary operator on the data query.

WCF OData Service

In Visual Studio 2013, there is a template to create a WCF OData service. So, we can easily create an OData Service using Visual Studio 2010.

Example of OData Service has been used

  1. Last (2010) football world cup (S.A), the scoring website was done using an OData Service.

Why should we use an OData Service? 

  1. OData is based on the REST architecture, so we can retrieve data based on an URL.
  2. It also supports HTTP, Atom Pub as well as JSON format.
  3. It has support for any type of data source. Even you can use a custom class as a data source.
  4. No need to create a proxy service object. So, it is lightweight to use.
  5. You can create your own custom methods and expose it.
  6. Since it is lightweight, the interaction between server and client is fast. Thus, performance is good.
  7. It offers full CRUD support by using the different HTTP methods:
    • GET: Gets one or many entries.
    • POST: Create a new entry.
    • PUT: Update an existing entry.
    • DELETE: Remove an entry.
  1. A WCF Data service can expose an entity model via an URI.
  2. A WCF Data service could be consumed by any type of client like Windows, SilverLight, Web, AJAX and console.

Limitations

  1. Since it is purely URL based, it is less secure.
  2. Not every query operator in LINQ is available in OData like Filter, Skip, Take etc.

Working of a WCF Data Service

There are five components.

  1. DataBase.
  2. Data Access layer using ADO.Net Entity model or LINQ.
  3. Entity Model Implementing Iqueryable and Iupdatable Interface.
  4. WCF Data Service exposing CRUD Operations on entity model as REST Service.
  5. Consuming it on various types of clients.

Supported Message Format

  1. JSON
  2. XML (ATOM)

Copyright © All Rights Reserved - C# Learners