[Dev Tip] WCF Contract Inheritance problem Explained simply


I have run into a problem lately where i couldn’t pass a subclass instead of the base class in WCF. I run a search about a topic but i didn’t find a proper solution nor a proper explanation. So, i said to myself, this is a good article subject to write about.


Let’s do a brief description of our current situation: We have a WCF Application where the service (a.k.a Factory) sends informations to the client (a.k.a Factory Client).

First, this is the service contract:

    public interface IFactory
        string TryService(string echo);
        Result GetResult();

It contains two methods,

  1. TryService is a dummy method to test our WCF communication
  2. GetResult will create a dictionary<string, BaseElement> and send it back to the client

Second, the service implementation:

    public class Factory : IFactory
        public string TryService(string echo)
            return echo;
        public Result GetResult()
            var baseElem = new BaseElement
                BaseName = "BaseElement"
            return new Result()
                Elements = new Dictionary<string, BaseElement>
                    {"1", baseElem}

Our BaseElement class implementation:

    public class BaseElement
        public string BaseName { get; set; }

Our service configuration:

<?xml version="1.0" encoding="utf-8" ?>
    <compilation debug="true" />
      <service name="ElementService.Factory">
        <endpoint address="/FactoryService" behaviorConfiguration=""
          binding="basicHttpBinding" bindingConfiguration="" contract="ElementService.IFactory" />
            <add baseAddress="http://localhost/services" />
          <serviceMetadata httpGetEnabled="True"/>
          <serviceDebug includeExceptionDetailInFaults="False" />

The client implementation:

    class FactoryClient : IFactory
        public FactoryClient()
            var myBinding = new BasicHttpBinding();
            var endpoint = new EndpointAddress("http://localhost/services/FactoryService");
            ChannelFactory = new ChannelFactory<IFactory>(myBinding, endpoint);
        public string TryService(string echo)
            var client = ChannelFactory.CreateChannel();
            var response = client.TryService(echo);
            return response;
        public Result GetResult()
            var client = ChannelFactory.CreateChannel();
            var response = client.GetResult();
            return response;
        public ChannelFactory<IFactory> ChannelFactory { get; set; }

Our Program:

    class Program
        static void Main(string[] args)
            FactoryClient factory = new FactoryClient();
            var tt = factory.TryService("Bill");
            Console.WriteLine("Service says: " + tt);
            var res = factory.GetResult();
            foreach (var item in res.Elements)
                Console.WriteLine("Key :" + item.Key + " Value: " + item.Value);

Til this far, everything should work fine and the expected result when you run the program is


Now let’s suppose we have a new class (a.k.a SuperElement) that inherits from BaseElement:

    public class SuperElement : BaseElement
        public string SuperName { get; set; }

It’s perfectly fine to edit my GetResult method on the service side to return a SuperElement as well:

        public Result GetResult()
            var baseElem = new BaseElement
                BaseName = "BaseElement"
            var superElem = new SuperElement
                SuperName = "SuperElement"
            return new Result()
                Elements = new Dictionary<string, BaseElement>
                    {"1", baseElem},
                    {"2", superElem},

Except that when i run my client invokes the GetResult method on the service, we get an exception like this

An error occurred while receiving the HTTP response to http://localhost/services/FactoryService. The reason may be that the connection endpoint service does not use the HTTP protocol. This may also be due to the fact that a context of HTTP request was ignored by the server (possibly due to the discontinuation of service). For more information, check the server logs.

So what just happened here?


Let’s remind ourselves about inheritance:

    public class A

    public class B : A

For a base class A, any subclass B inheriting from A is considered an A class as well, but an A class is not necessarly a B class.

This is true because whenever you create a new instance of the sub class, compiler starts by assigning the base class to the object memory state then adds the subclass parts to finalize the instanciation just like this figure explains:

When a method expecting a reference to the base class receives a refrence to a sub class instead, it accepts it because it’s also a reference to the base class. However, this is not the case with WCF because objects are not passed by reference but by value !

Passing elements by value is better than by reference in situations of multi-level applications where every layer has the freedom to handle classes in its own way. In addition, this behaviour favours application interoperability, asynchronous calling and long workflows.

In our case, after creating the Dictionary<string, BaseElement>, the service serializes it to send it inside the WCF message. Upon receiving the WCF message, the client tries to deserialize it using the service contract as a guiding map. As mentionned in the service contract, the object should be Dictionary<string, BaseElement> but the client finds another object (which is SuperElement). Because he was not expecting such type, the client raises an exception !


With the introduction of .Net framework 3.0, WCF created a workaround for this kind of problems using an attribute called KnownType. Let’s see how to use it before explaining what is it about:

    public class BaseElement
        public string BaseName { get; set; }

Using KnowType attribute, we are telling the service/client that if you find a SuperElement instance instead of a BaseElement, then it’s perfectly fine and you can serialize/deserialize it too. Magically, the serialization/deserialization happens according to the subclass type (SuperElement) instead of the base class (BaseElement).

The KnowType attribute affects all operations and contracts, thus autorising the acceptance of the sub class instead of the base class. Furthermore, it allows the client to pass in sub classes as well to the service by including the sub class in metadata.


You have to keep in mind three points:

  • You must always include the hole hierarchy to enable sub class substitution. Adding a sub class does not add its base class !
  • KnownType attribute reduces the performance of your application. This cost becomes significant when you start to make substitutions everywhere in you application. You might want to take a second look at your application architecture in that case.
  • If having many base class/sub classe is inevitable, microsoft provided other alternatives such as:
    • ServiceKnowType attribute
    • Write the list of awaited classes to be substituted inside the application configuration file section System.runtime.serialization
    • Best solution is available on .Net 4.0: DataContractResolver is powerful tool that intercepts serialization/derserialization process allowing you to alter the behaviour through your own code.

I hope this article will be a good use for you.


All credits go to an MSDN article written about this same subject. I strongly recommend reading the part about DataContractResolver.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Bilel Msekni

France France

[Dev Tip] 10 Good Practices for ASP.NET MVC Apps

When you open up Visual Studio 2013 with the intent of building a new ASP.NET MVC 5 project, you find only one option: an ASP.NET Web Application. This is great, as it represents a moment of clarity in a whirlpool of similar-looking and confusing options. So you click and are presented with various options as to the type of project to create. You want ASP.NET MVC, right? So you pick up the MVC option. What you obtain is a no-op demo application that was probably meant to give you an idea of what it means to code for ASP.NET MVC. Even though the result does nothing, the resulting project is fairly overloaded.

You’ll also find several Nuget packages and assemblies referenced that are not required by the sample application, yet are already there to save time for when you need them in action. This is not a bad idea in theory, as nearly any ASP.NET website ends up using jQuery, Bootstrap, Modernizr, Web Optimization, and others. And if you don’t like it, you still have the option of starting with an empty project and adding MVC scaffolding. This is better, as it delivers a more nimble project even though there are many references that are useless at first. The truth is that any expert developer has his own favorite initial layout of the startup project, including must-have packages and scripts.

Although I may be tempted, I don’t want to push my own ideal project layout on you. My purpose, instead, is applying the Occam’s Razor to the ASP.NET MVC project templates that you get in Visual Studio 2013. I’ll start with the organization of project folders and proceed through startup code, bundling, HTML layout, controllers, layers, HTTP endpoints, and multi-device views. Overall, here are ten good practices for sane ASP.NET MVC 5 development.

#1: Project Folders and Namespaces

Let’s say you used the Visual Studio 2013 project template to create a new project. It works, but it’s rather bloated. Figure 1 shows the list of unnecessary references detected by ReSharper.

Figure 1 : Unnecessary references in the ASP.NET MVC project built with the default Visual Studio 2013 template

It’s even more interesting to look at the remaining references. Figure 2 shows what you really need to have referenced in order to run a nearly dummy ASP.NET MVC application.

Figure 2 : Strictly required assemblies in a basic ASP.NET MVC 5 project

Here’s the minimal collection of Nuget packages you need in ASP.NET MVC.


The project contains the folders listed in Table 1.

When you start adding Nuget packages, some other conventions start appearing such as the Scripts folder for Modernizr and for jQuery and its plugins. You may also find a Content folder for Bootstrap style sheets and a separate Fonts folder for Bootstrap’s glyph icons.

I find such a project structure rather confusing and usually manage to clean it up a little bit. For example, I like to place all content (images, style sheets, scripts, fonts) under the same folder. I also don’t much like the name Models. (I don’t like the name App_Start either but I’ll return to that in a moment.) I sometimes rename Models to ViewModels and give it a structure similar to Views: one subfolder per controller. In really complex sites, I also do something even more sophisticated. The Models folder remains as is, except that two subfolders are addedLInput and View, as shown in Figure 3.

Figure 3 : Content and Models folder internal structure

Generally speaking, there are quite a few flavors of models. One is the collection of classes through which controllers receive data. Populated from the model binding layer, these classes are used as input parameters of controller methods. I collectively call them the input model and define them in the Input subfolder. Similarly, classes used to carry data into the Razor views collectively form the view model and are placed under the Models/View folder. Both input and view models are then split on a per-controller basis.

One more thing to note is the matching between project folders and namespaces. In ASP.NET it’s a choice rather than an enforced rule. So you can freely decide to ignore it and still be happy, as I did for years. At some point—but it was several years ago—I realized that maintaining the same structure between namespaces and physical folders was making a lot of things easier. And when I figured out that code assistant tools were making renaming and moving classes as easy as click-and-confirm, well, I turned it into enforcement for any of my successive projects.

#2 Initial Configuration

A lot of Web applications need some initialization code that runs upon startup. This code is usually invoked explicitly from the Application_Start event handler. An interesting convention introduced with ASP.NET MVC 4 is the use of xxxConfig classes. Here’s an example that configures MVC routes:

publicclassRouteConfig{publicstaticvoidRegisterRoutes(RouteCollection routes){
                controller ="Home",
                action ="Index",
                id =UrlParameter.Optional});}}

The code in global_asax looks like this:


For consistency, you can use the same pattern to add your own classes that take care of application-specific initialization tasks. More often than not, initialization tasks populate some ASP.NET MVC internal dictionaries, such as the RouteTable.Routes dictionary of the last snippet (just after the heading for #2).For testability purposes, I highly recommend that xxxConfig methods are publicly callable methods that get system collections injected. As an example, here’s how you can arrange unit tests on MVC routes.

[TestMethod]publicvoidTest_If_Given_Route_Works(){// Arrangevar routes =newRouteCollection();MvcApplication.RegisterRoutes(routes);RouteData routeData =null;// Act & Assert whether the right route was foundvar expectedRoute ="{controller}/{action}/{id}";
    routeData =GetRouteDataFor("~/product/id/123",
                                routes);Assert.AreEqual(((Route) routeData.Route).Url,

Note that the code snippet doesn’t include the full details of the code for customGetRouteDataFor method. Anyway, the method uses a mocking framework to mockHttpContextBase and then invokes method GetRouteData on RouteCollectionpassing the mocked context.

var routeData = routes.GetRouteData(httpContextMock);

Many developers just don’t like the underscore convention in the name of some ASP.NET folders, particularly the App_Start folder. Is it safe to rename this folder to something like Config? The answer is: it’s generally safe but it actually depends on what you do in the project.

The possible sore point is the use of the WebActivator Nuget package in the project, either direct or through packages that have dependencies on it. WebActivator is a package specifically created to let other Nuget packages easily add startup and shutdown code to a Web application without making any direct changes to global.asax. WebActivator was created only for the purposes of making Nuget packages seamlessly extend existing Web applications. As WebActivator relies on an App_Start folder, renaming it may cause you some headaches if you extensively add/refresh Nuget packages that depend on WebActivator. Except for this, there are no problems in renaming App_Start to whatever you like most.

#3 Bundling and Minifying CSS Files

Too many requests from a single HTML page may cause significant delays and affect the overall time-to-last-byte metrics for a site. Bundling is therefore the process of grouping distinct resources such as CSS files into a single downloadable resource. In this way, multiple and logically distinct CSS files can be downloaded through a single HTTP request.

Minification, on the other hand, is the process that removes all unnecessary characters from a text-based resource without altering the expected functionality. Minification involves shortening identifiers, renaming functions, removing comments and white-space characters. In general, minification refers to removing everything that’s been added mostly for readability purposes, including long descriptive member names.

Bundling requires the Microsoft ASP.NET Web Optimization Framework available as a Nuget package. Downloading the Optimization Framework also adds a few more references to the project. In particular, they are WebGrease and Microsoft Infrastructure. These, in turn, bring their own dependencies for the final graph, shown in Figure 4.

Figure 4 : Graph of Nuget dependencies for bundling and minification

Bundles are created programmatically during the application startup in global.asax. Also in this case, you can use the xxxConfig pattern and add some BundlesConfig class to the App_Startup folder. The BundleConfig class contains at least one method with code very close to the following snippet.

publicstaticvoidRegisterBundles(BundleCollection bundles){

The code creates a new bundle object for CSS content and populates it with distinct CSS files defined within the project. Note that the Include method refers to physical paths within the project where the source code to bundle is located. The argument passed to the StyleBundle class constructor instead is the public name of the bundle and the URL through which it will be retrieved from pages. There are quite a few ways to indicate the CSS files to bundle. In addition to listing them explicitly, you can use a wildcard expression:


Once CSS bundles are defined invoking them is as easy as using the Styles object:


As you can figure from the last two snippets, ASP.NET optimization extensions come with two flavors of bundle classes: the Bundle class and the StyleBundle class. The former only does bundling; the latter does both bundling and minification. Minification occurs through the services of an additional class. The default CSS minifier class is CssMinify and it is based on some logic packaged in WebGrease. Switching to a different minifier is easy too. All you do is using a different constructor on the StyleBundle class. You use the constructor with two arguments, the second of which is your own implementation of IBundleTransform.

#4 Bundling and Minifying Script Files

Bundling and minification apply to script files in much the same way as bundling and minifying CSS files. The only minor difference is that for frequently used script files (such as jQuery) you might want to use a CDN for even better performance. In operational terms, bundling and minifying script files requires the same process and logic as CSS files. You use the Bundle class if you’re only concerned about packing multiple files together so that they are captured in a single download and cached on the client. Otherwise, if you also want minifying, you use the ScriptBundle class.


Like StyleBundle, ScriptBundle also features a constructor that accepts an IBundleTransform object as its second argument. This object is expected to bring in some custom logic for minifying script files. The default minifier comes from WebGrease and corresponds to the JsMinify class.

It’s very common today to arrange very complex and graphically rich Web templates that are responsive to changes in the browser’s window size and that update content on the client side through direct access to the local DOM. All this can happen if you have a lot of script files. It’s not, for the most part, JavaScript code that you write yourself. It’s general-purpose JavaScript that forms a framework or a library. In a nutshell, you often end up composing your client-side logic by sewing together multiple pieces, each of which represents a distinct download.

Considering the general recommendation of using as few script endpoints as possible—and bundling does help a lot in that regard—the optimal position of the <script> tags in the body of the HTML page is an open debate. For quite some time, the common practice was to put <script> elements at the end of the document body. This practice was promoted by Yahoo and aimed at avoiding roadblocks during the rendering of the page. By design, in fact, every time the browser encounters a <script> tag, it stops until the script has been downloaded (or recovered from the local cache) and processed.

It’s not mandatory that all script files belong at the bottom. It’s advisable that you distinguish the JavaScript that’s needed for the page to render from the JavaScript that serves other purposes. The second flavor of JavaScript can safely load at the bottom. Well, mostly at the bottom. Consider that as the page renders the user interface in the browser, users may start interacting with it. In doing so, users may trigger events that need some of the other JavaScript placed at the bottom of the page and possibly not yet downloaded and evaluated. If this is your situation, consider keeping input elements that the user can interact with disabled until it’s safe to use them. The ready event of jQuery is an excellent tool to synchronize user interfaces with downloaded scripts. Finally, consider some techniques to load scripts in parallel so that the overall download time becomes the longest of all instead of the sum of all downloads. The simplest way you can do this is through a programmatically created <script> element. You do this using code, as shown below.

var h = document.getElementsByTagName("HEAD")[0];var script = document.createElement("script");
script.type ="text/javascript";
script.onreadystatechange =function(){...};
script.onload =function(){...};
script.onerror =function(){...};
document.src ="...";

Script elements are appended to the HEAD element so that parallel download begins as soon as possible. Note that this is the approach that most social Web sites and Google Analytics use internally. The net effect is that all dynamically created elements are processed on different JavaScript threads. This approach is also employed by some popular JavaScript loader frameworks these days.

#5 The Structure of the _Layout File

In ASP.NET MVC, a layout file is what a master page was in classic Web Forms: the blueprint for multiple pages that are ultimately built out of the provided template. What should you have in a master view? And in which order?

With the exceptions and variations mentioned a moment ago for parallelizing the download of multiple scripts, there are two general rules that hold true for the vast majority of websites. The first rule says: Place all of your CSS in the HEAD element. The second rule says: Place all of your script elements right before the closing tag of the <body> element.

There are a few other little things you want to be careful about in the construction of the layout file(s) for your ASP.NET MVC application. First off, you might want to declare explicitly that the document contains HTML5 markup. You achieve this by having the following markup at the very beginning of the layout and subsequently at the beginning of each derived page.

<!DOCTYPE html>

The DOCTYPE instructs older browsers that don’t support specific parts of HTML5 to behave well and correctly interpret the common parts of HTML while ignoring the newest parts. Also, you might want to declare the character set in the HEAD block.


The charset attribute is case-insensitive, meaning that you can indicate the character set name as UTF-8, utf-8 or otherwise. In general, you don’t use other character sets than UTF-8, as it’s the default encoding for Web documents since HTML4, which came out back in 1999. As far as IIS and ASP.NET are concerned, you have other ways to set the character set. For example, you can type it in the <globalization> section of the web.config file. Having it right in each page just adds clarity. An interesting consequence of clarifying the character set being used is that you can avoid using HTML entities and type special characters directly in the source. Canonical examples are the copyright (&copy;), trademark (&reg;), euro (&euro), dashes (&mdash;), and more. The only HTML entities you should use are those that provide the text version of reserved markup characters, such as less-than, greater-than, and ampersand.

Another rather important meta-tag you’ll want to have is the viewport meta-tag whose usage dates back to the early days of smartphones. Most mobile browsers can be assumed to have a rendering area that’s much larger than the physical width of the device. This virtual rendering area is just called the “viewport.” The real size of the internal viewport is browser-specific. However, for most smart phones, it’s around 900 pixels. Having such a large viewport allows browsers to host nearly any Web page, leaving users free to pan and zoom to view content, as illustrated inFigure 5.

Figure 5 : The viewport in a browser

The viewport meta-tag is a way for you to instruct the browser about the expected size of the viewport.


In this example, you tell the browser to define a viewport that is the same width as the actual device. Furthermore, you specify that the page isn’t initially zoomed and worse, users can’t zoom in. Setting the width property to the device’s width is fairly common, but you can also indicate an explicit number of pixels.

In ASP.NET MVC, pay a lot of attention to keeping the layout file as thin as possible. This means that you should avoid referencing from the layout file CSS and script files that are referenced by all pages based on the layout. As developers, we certainly find it easier and quicker to reference resources used by most pages right from the layout file. But that only produces extra traffic and extra latency. Taken individually, these extra delays aren’t significant, except that they sum up and may add one or two extra seconds for the page to show and be usable.

        © @DateTime.Now.Year - ASP.NET QuickUp

The markup above indicates that the entire body of the page replaces @RenderBody. You can define custom sections in a layout file using the following line:


The name of the section is unique but arbitrary and you can have as many sections as you need with no significant impact on the rendering performance. You just place a @RenderSection call where you want the derived page to inject ad hoc content. The example above indicates a section where you expect the page to insert custom script blocks. However, there’s nothing that enforces a specific type of content in a section. A section may contain any valid HTML markup. If you want to force users to add, say, script blocks, you can proceed as follows:


In this case, overridden sections are expected to contain data that fits in the surrounding markup; otherwise, a parsing error will be raised. In a derived page, you override a section like this:


#6 (Don’t) Use Twitter Bootstrap

Twitter Bootstrap is quickly becoming the de-facto standard in modern Web development, especially now that Visual Studio 2013 incorporates it in the default template for ASP.NET MVC applications. Bootstrap essentially consists of a large collection of CSS classes that are applicable directly to HTML elements and in some cases to special chunks of HTML markup. Bootstrap also brings down a few KBs of script code that extends CSS classes to make changes to the current DOM.

As a matter of fact, with Bootstrap, you can easily arrange the user interface of Web pages to be responsive and provide advanced navigation and graphical features.

The use of Bootstrap is becoming common and, as popularity grows, also controversial. There are reasons to go for it and reasons for staying away from it. My gut feeling is that Bootstrap is just perfect for quick projects where aesthetics are important but not fundamental, and where you need to provide pages that can be decently viewed from different devices with the lowest possible costs. Key arguments in favor of Twitter Bootstrap are its native support for responsive Web design (RWD), deep customizability, and the not-secondary fact that it’s extremely fast to learn and use.

Bootstrap was created as an internal project at Twitter and then open-sourced and shared with the community. When things go this way, there are obvious pros and cons. For Web developers, it’s mostly about good things. Bootstrap offers a taxonomy of elements that you want to have in Web pages today: fluid blocks, navigation bars, breadcrumbs, tabs, accordions, rich buttons, composed input fields, badges and bubbles, lists, glyphs, and more advanced things, such as responsive images and media, auto-completion, and modal dialogs. It’s all there and definable through contracted pieces of HTML and CSS classes. Put another way, when you choose Bootstrap, you choose a higher level markup language than HTML. It’s much the same as when you use jQuery and call it JavaScript. The jQuery library is made of JavaScript but extensively using it raises the abstraction level of JavaScript.

By the same token, using Bootstrap extensively raises the abstraction level of the resulting HTML and makes it look like you’re writing Bootstrap pages instead of HTML pages. This is just great for developer-centric Web solutions. It’s not good for Web designers and for more sophisticated projects where Web designers are deeply involved.

When you choose Bootstrap. you choose a higher-level markup language than HTML. It’s much the same as when you use jQuery and call it JavaScript.

From a Web designer’s perspective, Twitter Bootstrap is just a Twitter solution and even theming it differently is perceived like work that takes little creativity. From a pure Web design perspective, Bootstrap violates accepted (best) practices. In particular, Bootstrap overrides the HTML semantic and subsequently, presentation is no longer separate from the content. Not surprisingly, when you change perspective, the same feature may turn from being a major strength to being a major weakness. Just because Bootstrap overrides the HTML semantic, it tends to favor an all-or-nothing approach. This may be problematic for a Web design team that joins an ongoing project where Bootstrap is being used. In a nutshell, Bootstrap is an architectural decision—and one that’s hard to change on the go. So, yes, it makes presentation tightly bound to content. Whether this is really an issue for you can’t be determined from the outside of the project.

Last but not least, the size of Twitter Bootstrap is an issue. Minified, it counts for about 100K of CSS, 29K of JavaScript plus fonts. You can cut this short by picking exactly the items you need. The size is not an issue for sites aimed at powerful devices such as a PC, but Bootstrap for sites aimed at mobile devices may be a bit too much. If you’re going to treat desktop devices differently from mobile devices, you might want to look into the mobile-only version of Bootstrap that you find at .

#7 Keep Controllers Thin

ASP.NET MVC is often demonstrated in the context of CRUD applications. CRUD is a very common typology for applications and it’s a very simple typology indeed. For CRUD applications, a fat controller that serves any request directly is sometimes acceptable. When you combine the controller with a repository class for each specific resource you handle, you get good layering and achieve nifty separation of concerns.

It’s essential to note that the Model-View-Controller pattern alone is not a guarantee of clean code and neatly separated layers. The controller simply ensures that any requests are routed to a specific method that’s responsible for creating the conditions for the response to be generated and returned. In itself, an action method on a controller class is the same as a postback event handler in old-fashioned Web Forms applications. It’s more than OK to keep the controller action method tightly coupled to the surrounding HTTP context and access it from within the controller method intrinsic objects such as Session, Server, and Request. A critical design goal is keeping the controller methods as thin as possible. In this way, the controller action methods implement nearly no logic or very simple workflows (hardly more than one IF or two) and there’s no need to test them.

Figure 6 : A multi-layer architecture for an ASP.NET MVC application

The extra layer is the application layer and it consists of classes that typically map to controllers. For example, if you have HomeController, you might also want to have some HomeService class. Each action in HomeController ends up calling one specific method in HomeService. Listing 1 shows some minimalistic code to illustrate the pattern.

The Index method invokes the associated worker service to execute any logic. The service returns a view model object that is passed down to the view engine for the actual rendering of the selected Razor view. Figure 7 shows instead a modified project structure that reflects worker services and the application layer of the ASP.NET MVC application.

Figure 7 : The new project infrastructure for worker services and view models

#8 Membership and Identity

To authenticate a user, you need some sort of a membership system that supplies methods to manage the account of a user. Building a membership system means writing the software and the related user interface to create a new account and update or delete existing accounts. It also means writing the software for editing any information associated with an account. Over the years, ASP.NET has offered a few different membership systems.

Historically, the first and still largely used membership system is centered on the Membership static class. The class doesn’t directly contain any logic for any of the methods it exposes. The actual logic for creating and editing accounts is supplied by a provider component that manages an internal data store. You select the membership in the configuration file. ASP.NET comes with a couple of predefined providers that use SQL Server or Active Directory as the persistence layer. Using predefined providers is fine, as it binds you to a predefined storage schema and doesn’t allow any reuse of existing membership tables. For this reason, it’s not unusual that you end up creating your own membership provider.

Defining a custom membership provider is not difficult at all. All you do is derive a new class from MembershipProvider and override all abstract methods. At a minimum, you override a few methods such as ValidateUserGetUserCreateUser, and ChangePassword. This is where things usually get a bit annoying.

The original interface of the Membership API is way too complicated with too many methods and too many quirks. People demanded a far simpler membership system. Microsoft first provided the SimpleMembership provider and with Visual Studio 2013, what appears to be the definitive solution: ASP.NET Identity.

In the ASP.NET Identity framework, all of the work is coordinated by the authentication manager. It takes the form of the UserManager<T> class, which basically provides a façade for signing users in and out.

publicclassUserManager<T>where T :IUser{:}

The type T identifies the account class to be managed. The IUser interface contains a very minimal definition of the user, limited to ID and name. The ASP.NET Identity API provides the predefined IdentityUser type that implements the IUser interface and adds a few extra properties such as PasswordHash and Roles. In custom applications, you typically derive your own user type inheriting from IdentityUser. It’s important to notice that getting a new class is not required; you can happily work with native IdentityUser if you find its structure appropriate.

User data storage happens via the UserStore<T> class. The user store class implements the IUserStore interface that summarizes the actions allowed on the user store:

publicinterfaceIUserStore<T>:where T:IUser{TaskCreateAsync(T user);TaskDeleteAsync(T user);Task<T>FindByIdAsync(string userId);Task<T>FindByNameAsync(string userName);TaskUpdateAsync(T user);}

As you can see, the user store interface looks a lot like a canonical repository interface, much like those you might build around a data access layer. The entire infrastructure is glued together in the account controller class. The skeleton of an ASP.NET MVC account controller class that is fully based on the ASP.NET Identity API is shown in Listing 2.

The controller holds a reference to the authentication identity manager. An instance of the authentication identity manager is injected in the controller. The link between the user store and the data store is established in the ApplicationDbContext class. You’ll find this class defined by the ASP.NET MVC 5 wizard if you enable authentication in the Visual Studio 2013 project template.


The base IdentityDbContextclass inherits from DbContextand is dependent on Entity Framework. The class refers to an entry in the web.config file, where the actual connection string is read. The use of Entity Framework Code First makes the structure of the database a secondary point. You still need a well-known database structure, but you can have the code to create one based on existing classes instead of manual creation in SQL Server Management Studio. In addition, you can use Entity Framework Code First Migration tools to modify a previously created database as you make changes to the classes behind it.

Currently, ASP.NET Identity covers only the basic features of membership but its evolution is not bound to the core ASP.NET Framework. Features that the official interfaces don’t cover yet (such as enumerating users) must be coded manually, which brings you back to the handcrafted implementation of membership.

#9 Expose HTTP Endpoints

An architecture for Web applications that’s becoming increasingly popular is having a single set of HTTP endpoints—collectively known as Web services—consumed by all possible clients. Especially if you have multiple clients (like mobile applications and various Web frontends) a layer of HTTP endpoints is quite helpful to have. Even if you only have a single client frontend, a layer of HTTP endpoints is helpful as it allows you to have a bunch of Ajax-based functionalities integrated in HTML pages. The question is: How would you define such endpoints?

If you need an API—or even a simple set of HTTP endpoints—exposed out of anything but ASP.NET MVC (such as Web Forms or Windows services) using Web API is a no-brainer. But if all you have is an ASP.NET MVC application, and are tied to IIS anyway, you can simply use a separate ASP.NET MVC controller and make it return JSON.

There are many posts out there calling for a logical difference between Web API controllers and ASP.NET MVC controllers. There’s no doubt that a difference exists because overall Web API and ASP.NET MVC have different purposes. Anyway, the difference becomes quite thin and transparent when you consider it from the perspective of an ASP.NET MVC application.

With plain ASP.NET MVC, you can easily build an HTTP façade without learning new things. In ASP.NET MVC, the same controller class can serve JSON data or an HTML view. However, you can easily keep controllers that return HTML separate from controllers that only return data. A common practice consists in having an ApiController class in the project that exposes all endpoints expected to return data. In Web API, you have a system-provided ApiController class at the top of the hierarchy for controllers. From a practical perspective, the difference between ASP.NET MVC controllers and Web API controllers hosted within the same ASP.NET MVC is nearly non-existent. At the same time, as a developer, it’s essential that you reason about having some HTTP endpoints exposed in some way.

Web API and ASP.NET MVC have different purposes.

#10 Use Display Modes

One of the best-selling points of CSS is that it enables designers and developers to keep presentation and content neatly separated. Once the HTML skeleton is provided, the application of different CSS style sheets can produce even radically different results and views. With CSS, you can only hide, resize, and reflow elements. You can’t create new elements and you can add any new logic for new use-cases.

In ASP.NET MVC, a display mode is logically the same as a style sheet except that it deals with HTML views instead of CSS styles. A display mode is a query expression that selects a specific view for a given controller action. In much the same way, the Web browser on the client processes CSS media query expressions and applies the appropriate style sheet; a display mode in server-side ASP.NET MVC processes a context condition and selects the appropriate HTML view for a given controller action.

Display modes are extremely useful in any scenario where multiple views for the same action can be selected based on run-time conditions. The most compelling scenario, however, is associated with server-side device detection and view routing. By default, starting with ASP.NET MVC 4, any Razor view can be associated with a mobile-specific view. The default controller action invoker automatically picks up the mobile-specific view if the user agent of the current request is recognized as the user agent of a mobile device. This means that if you have a pair of Razor views such as index.cshtml and index.mobile.cshtml, the latter will be automatically selected and displayed in lieu of the former if the requesting device is a mobile device. This behavior occurs out of the box and leverages display modes. Display modes can be customized to a large extent. Here’s an example:

var tablet =newDefaultDisplayMode("tablet"){ContextCondition=(c =>IsTablet(c.Request))};var desktop =newDefaultDisplayMode("desktop"){ContextCondition=(c =>returntrue)};

The preceding code goes in the Application_Start event of global.asax and clears default existing display modes and then adds a couple of user-defined modes. A display mode is associated with a suffix and a context condition. Display modes are evaluated in the order in which they’re added until a match is found. If a match is found—that is, if the context condition holds true—then the suffix is used to complete the name of the view selected. For example, if the user agent identifies a tablet, then index.cshtml becomes index.tablet.cshtml. If no such Razor file exists, the view engine falls back to index.cshtml.

Display modes are an extremely powerful rendering mechanism but all this power fades without a strong mechanism to do good device detection on the server side. ASP.NET lacks such a mechanism. ASP.NET barely contains a method in the folds of the HttpRequest object to detect whether a given device is mobile or not. The method is not known to be reliable and work with just any old device out there. It lacks the ability to distinguish between smartphones, tablets, Google glasses, smart TVs, and legacy cell phones. Whether it works in your case is up to you.

If you’re looking for a really reliable device detection mechanism, I recommend WURFL, which comes through a handy Nuget package. For more information on WURFL, you can check out my article that appeared in the July 2013 issue of CODE Magazine, available at the following URL: .

Display modes are extremely useful in any scenario where multiple views for the same action can be selected based on run time conditions.


ASP.NET MVC 5 is the latest version of Microsoft’s popular flavor of the ASP.NET platform. It doesn’t come with a full bag of new goodies for developers but it remains a powerful platform for Web applications. ASP.NET is continuously catching up with trends and developments in the Web space and writing a successful ASP.NET MVC application is a moving target. This article presented ten common practices to build ASP.NET MVC applications with comfort and ease.

Listing 1: A layered controller class

publicinterfaceIHomeService{IndexViewModelGetModelForIndex();}publicclassHomeController:Controller{privatereadonlyIHomeService _service;publicHomeController():this(newHomeService()){}publicHomeController(IHomeService service){
        _service = service;}publicActionResultIndex(){var model = _service.GetModelForIndex();returnView(model);}}publicclassViewModelBase{publicStringTitle{get;set;}}publicclassIndexViewModel:ViewModelBase{// More members here}

Listing 2. Sample account controller class

publicclassAccountController:Controller{publicUserManager<IdentityUser>UserManager{get;set;}publicAccountController(UserManager<IdentityUser> manager){UserManager= manager;}publicAccountController():this(newUserManager<IdentityUser>(newUserStore<IdentityUser>(newApplicationDbContext()))){}// Other members here}

Table 1: Typical project folders.

Folder name Intended goal
App_Data Contains data used by the application, such as proprietary files (e.g., XML files) or local databases
App_Start Contains initialization code. By default, it simply stores static classes invoked from within global.asax.
Controllers Folder conventionally expected to group all controllers used by the application
Models Folder conventionally expected to contain classes representing the rather nebulous MVC concept of “model”
Views Folder conventionally expected to group all Razor views used by the application. The folder is articulated in subfolders,one per controller

(From: http://www.codemag.com/Article/1405071)

[Discovery] Những cái “nhất” kỳ lạ ở thế giới động vật

Tóm tắt bài viết:

– Thế giới động vật có rất nhiều loài kỳ lạ mà chúng ta chưa biết.
– Trong số đó có những loài động vật tiến hóa để có thể thích nghi với điều kiện sống, sự tiến hóa này khiến chúng có những bộ phận cơ thể phát triển một cách không bình thường.
– Bạn có biết loài giun dây giày có thể có chiều dài thân lên tới 55m, hay loài hà chân tơ có dương vật với chiều dài gấp 5 lần cơ thể?

Thế giới tự nhiên xung quanh ta luôn ẩn chứa vô vàn những khám phá đa dạng trên mọi phương diện. Hệ sinh thái trái đất vô cùng đa dạng và mỗi loài động vật lại có những đặc điểm riêng để chúng ta phải chú ý. Với một số loài thì đó là trí khôn đáng ngạc nhiên như cá heo, tinh tinh, một số loài khác là với những tập tục khác thường như gấu ngủ đông, cá ngựa nuôi con …

Trong bài viết này, chúng ta sẽ khám phá và tổng kết một chút về khía cạnh tỉ lệ cơ thể khác thường ở một số loài động vật. Tỉ lệ cơ thể khác thường ở đây có thể là có một cái đuôi dài gấp đôi cơ thể hay một cái chân ngắn đột biến, tuy nhiên cấu trúc cơ thể của chúng không phải là dị tật mà chính là do sự tiến hóa của tự nhiên để thích hợp với hoàn cảnh. Những động vật được liệt kê dưới đây là những loài đã được tổng kết qua nhiều quá trình tìm hiểu, nghiên cứu và góp mặt trong danh sách những loài có tỉ lệ cơ thể khác thường nhất thế giới.

Chiếc vòi của bướm diều hâu vùng Madagasca

Những cái "nhất" kỳ lạ ở thế giới động vật

Bình thường chúng ta đã khá quen thuộc với những chiếc vòi của những loài như chim ruồi hay bướm đêm để thăm dò hay hút mật hoa hiệu quả. Và với loài bướm diều hâu Madagasca cũng vậy, vòi của chúng được sử dụng để hút mật từ hoa lan. Với đặc trưng môi trường cũng như hoàn cảnh, tạo hóa đã cho loài này một chiếc vòi có chiều dài đột biên để thực hiện nhiệm vụ của mình. Chiếc vòi của loài bướm này dài 28cm gấp 3 lần chiều dài cơ thể của chúng, chuyên để hút mật từ loài hoa phong lan có nhụy nằm ở rất sâu.

Trong thế giới động vật, tỉ lệ chiếc vòi và cơ thể của bướm Madagasca có thể nói là độc nhất vô nhị. Không những thế, chiếc vòi này còn có thể thu vào cuộn chặt trong miệng. Tính năng này giúp cho chúng tránh được những bất tiện khi di chuyển và sự tấn công của những loài khác. Điều thú vị là sự tồn tại của loài này đã được nhà sinh vật học nổi tiếng Charles Darwin tiên đoán từ nhiều thập kỉ trước khi loài này chính thức được tìm thấy trên đảo vào năm 1903.

Chiếc đuôi ruy băng lông vũ của loài Astrapia

Những cái "nhất" kỳ lạ ở thế giới động vật

Astrapia là một loài chim thiên đường và điểm đặc biệt độc nhất vô nhị của chúng chính là chiếc đuôi lông vũ dài màu trắng nổi bật. Đuôi của chúng được đánh giá là chiếc đuôi lông vũ dài nhất so với kích thước cơ thể của các loài chim. Loài chim Astrapia có nguồn gốc từ các khu vực rừng núi vùng New Guinea. Chiếc đuôi mà chúng sở hữu có chiều dài gấp 3 lần chiều dài cơ thể chúng. Lông đuôi của chúng có thể có độ dài tới hơn 1 mét trong khi cơ thể chúng chỉ dài khoảng hơn 30 cm.

Chiếc đuôi dài của nó lúc đầu được đánh giá là một trở ngại vô cùng lớn với cuộc sống hàng ngày của chúng, nó có thể bị mắc ở bất cứ đâu và làm giảm tốc độ di chuyển của loài chim này. Đôi khi nó còn làm loài chim này khó bay vì tình trạng mất cân bằng trọng lượng cơ thể. Tác dụng thực sự của nó chỉ được phát huy vào mùa sinh sản, nó giúp những chú chim đực khoe mẽ và thu hút bạn tình. Tuy nhiên nếu để đánh giá thì nó vẫn gây ra nhiều rắc rối hơn là việc giúp ích.

Chim ruồi và chiếc mỏ dài kì lạ

Những cái "nhất" kỳ lạ ở thế giới động vật

Chúng ta đã bắt gặp rất nhiều loài chim với những chiếc mỏ khá nhỏ nhắn đáng yêu hoặc to dùng để chứa đồ ăn dự trữ. Tuy nhiên lần này chúng ta sẽ nói đến một loài chim có vẻ sẽ bay lượn khá khó khăn bởi chiếc mỏ quá dài của chúng – đó là chim ruồi.

Sự thích nghi về môi tường đã buộc nó phải phát triển một bộ phận – chiếc mỏ – trở nên khá kì lạ. Chiếc mỏ này sẽ giúp con chim tận dụng lợi thế với những thực phẩm chuyên biệt – hoa vân anh và một số hoa có nhụy sâu khác. Loài này là loài chim duy nhất trên thế giới có chiếc mỏ dài hơn chính cơ thể mình. Bình thường, mỏ của chim ruồi sẽ kéo dài khoảng hơn 10 cm quá đầu và đuôi. Không những thế, chiếc lưỡi thậm chí còn dài hơn cho phép loài chim này hút mật của gần như mọi loài hoa mà chúng tiếp cận. Loài chim này tồn tại ở Nam Mỹ với số lượng cá thể đáng kinh ngạc và hầu như không có sự cạnh tranh về thức ăn.

Chim cà kheo cánh đen

Những cái "nhất" kỳ lạ ở thế giới động vật

Hầu hết các loài chim đều có đôi chân khá cân đối thậm chí bé hơn kích thước cơ thể một chút. Nhưng điều này không đúng với chim cà kheo cánh đen. Đúng như cái tên của nó vậy, đôi chân của loài này là hai chiếc cà kheo đích thực. Nguyên nhân cho sự kì lạ này chính là do những áp lực về sự thích nghi. Do đó không chỉ mình loài chim cà kheo mà còn bao gồm một số loài như diệc, cò, chim hồng hạc đều phát triển những đôi chân dài, giúp chúng kiếm ăn dễ dàng trong nước mà không cần thực sự biết bơi.

Vượt qua tất cả những loài nói trên, đôi chân của chim cà kheo giữ kỉ lục là đôi chân dài nhất so với tỉ lệ cơ thể, thậm chí loài đà điểu cũng không theo kịp được tỉ lệ này. Loài chim này có chiều dài cơ thể từ 35-40 cm tính từ đầu mỏ tới cuối đuôi và cẳng của chúng dài 17-24 cm. Chúng ta dễ dạng có thể thấy đôi chân đã chiếm tới 60% chiều cao của toàn bộ cơ thể. Đôi chân của chúng không những dài mà còn có màu đỏ trông khá nổi bật.

Giun dây giày với chiều dài không tưởng

Những cái "nhất" kỳ lạ ở thế giới động vật

Chúng ta đều biết rằng hầu hết các loài giun, sâu đều có thân hình mảnh và dài. Bình thường chúng ta có thể đã được tiếp xúc với nhiều loại giun mà nghĩ rằng chúng đã rất dài như giun đũa, giun đất … Tuy nhiên độ dài cơ thể của giun dây giày sẽ khiến bạn phải ngạc nhiên. Loài giun dây giày là một loài không phân đốt , chính vì sự không phân đốt mà nó có được tiềm năng tăng trưởng đáng kinh ngạc và dường như không có giới hạn. Chiều dài phát triển lên tới 9m là điều hết sức bình thường và mẫu vật dài nhất được biết đến của loài này có chiều dài lên tới 55m. Khi được đưa lên mặt đất, bạn có thể thấy buồn nôn khi một con sâu dây giày có bề ngoài giống như một bộ ruột dài ngoằng.

Loài động vật ghê rợn này còn sản xuất và tiết ra một loại chất nhờn cay khó chịu. Tác dụng của chất nhờn này là đuổi kẻ thù khi chúng đền gần. Chính điều này đã cho phép chúng tồn tại ở dưới đáy biến cho tới tận bây giờ dù đây được coi là một loài động vật có từ thời xa xưa.

Dương vật của loài hà chân tơ

Những cái "nhất" kỳ lạ ở thế giới động vật

Hà hay hà biển là một loại động vật chân khớp đặc biệt, gần giống với loài hàu biển . Hà chỉ sống ở vùng nước mặn, thường là vùng nước nông và thủy triều. Hà là loài sống bám trên các vách đá, không di chuyển trong suốt cuộc đời. Hiện nay người ta đã biết tên khoảng 1.220 loài hà. Phần ruột của con hà trông không khác gì bên trong con hàu – một động vật thân mềm. Các nhà khoa học cũng đã nhầm lẫn trong một thời gian dài và ngay đến bây giờ nhiều người vẫn cho rằng hà và hàu có họ hàng với nhau. Thật khó tin là con vật không biết bơi này có họ với tôm và cua

Trong thế giới động vật, nếu như cá voi xanh được biết đến như là loài có dương vật lớn nhất thì loài hà chân tơ lại là loài có nhiều dương vật nhất. Thực tế điều này nghe có vẻ quái dị nhưng nó sẽ giúp cho loài này với lối sống neo đậu và cần thiết để giao phối trực tiếp. Thậm chí dương vật của chúng còn có thể kéo dãn và kích thước thay đổi tùy vào điều kiện môi trường. Theo nghiên cứu tại khoa sinh học đại học Alberta, người ta thấy rằng dương vật của chúng trở nên dài và mỏng hơn trong điều kiện sóng nhẹ và trở nên dày, ngắn hơn trong những điều kiện khắc nghiệt hơn. Dương vật của chúng có thể trở nên dài gấp 8 lần chiều dài của cơ thể.

Chiếc lưỡi dài của loài dơi hút mật

Những cái "nhất" kỳ lạ ở thế giới động vật

Thực tế bộ dơi là bộ có số lượng loài nhiều thứ hai trong lớp Thú với khoảng 1.100 loài, chiếm 20% động vật có vú. Khoảng 70% số loài dơi ăn sâu bọ, số còn lại chủ yếu ăn hoa quả và chỉ có vài loài ăn thịt. Dơi cần thiết cho sinh thái bởi chúng đóng vai trò thụ phấn hoa hay phát tán hạt cây, sự phân tán của nhiều loài cây lệ thuộc hoàn toàn vào dơi. Một trong những loài dơi nổi tiếng là loài dơi hút mật. Sự nổi tiếng của loài này chính là do chiếc lưỡi dài nổi tiếng của mình. Thực tế rằng không một loài vật nào có thể đọ được với tỉ lệ dài của lưỡi so với cơ thể với loài dơi hút mật. Một con dơi nhỏ với kích thước khoảng 5 cm có chiếc lưỡi dài khoảng 9 cm – gần như gấp đôi cơ thể.

Cơ chế và tác dụng của chiếc lưỡi gần giống với mỏ của loài chim ruồi. Loài dơi này sẽ bay qua bay lại những bông hoa có ống nhụy sâu và lấy mật. Sau khi xong việc, lưỡi của chúng sẽ tự động được rút lại và thu gọn trong lồng ngực con vật. Loài dơi này lần đầu tiên được tìm thấy vào năm 2005 tại Ecuador, trở thành một trong những loài dơi mới nhất được khoa học khám phá đến.

Cua cáy với chiếc càng khổng lồ


Cua cáy là loài cua đặc biệt rất dễ nhận biết với một chiếc càng có kích thước khổng lồ, những con cua đực thường có càng lớn hơn những con cái. Chiếc càng khổng lồ này cũng rất khỏe, nó có thể được sử dụng để giải quyết tranh chấp giữa những con cua đực với nhau trong cuộc chiến tranh giành bạn tình, tuy nhiên điều đặc biệt là chiếc càng này không được sử dụng nhiều trong việc tìm kiếm thức ăn.

Một nghiên cứu khác về loài cua này cho thấy một tác dụng khác của chiếc càng khổng lồ. Loài cua này thường được tìm thấy ở những bãi cát nóng do ánh sáng mặt trời chiếu vào, trong khi những con cua thường kiếm ăn trên bề mặt khiến nhiệt độ cơ thể của chúng luôn bị tăng cao. Nghiên cứu giữa những con cua đực bình thường và một con cua đực bị mất càng cho thấy nhiệt độ cơ thể của chúng khác nhau, con cua bị mất càng có nhiệt độ cơ thể cao hơn rất nhiều. Do đó các nhà khoa học phán đoán rằng chiếc càng của cua cáy còn có tác dụng điều chỉnh nhiệt độ cơ thể của chúng dưới cái nắng nóng của ánh mặt trời.

Tham khảo: Listverse

[Technology] UC Riverside phát triển thành công siêu tụ điện graphene mới, hiệu năng gấp đôi các sản phẩm hiện có

Từ trái sang là các nhà nghiên cứu Mihrimah Ozkan, Cengiz Ozkan và Zachary Favors.

Các nhà nghiên cứu tại đại học California, Riverside (UCR) đã vừa phát triển một loại siêu tụ điện graphene sử dụng một cấu trúc nano để tăng gấp đôi hiệu suất năng lượng so với các sản phẩm thay thế hiện có trên thị trường. Phát hiện này là một bước tiến quan trọng khác nhằm mở ra tiềm năng sử dụng các siêu tụ điện trên những chiếc xe chạy điện (EV) và thiết bị điện tử cá nhân với hiệu năng cao và sạc nhanh.

Siêu tụ điện là các thiết bị lưu trữ năng lượng rất ổn định và bền với mật độ năng lượng cao (điện năng/đơn vị khối lượng) nhưng năng lượng riêng rất thấp (năng lượng lưu trữ/đơn vị khối lượng). Điều này có nghĩa siêu tụ điện có thể cung cấp một lượng lớn điện năng nhưng chỉ trong vài giây một lần.

Một nhóm các nhà nghiên cứu dẫn đầu bởi giáo sư Cengiz S. Ozkan tại UCR mới đây đã phát triển một thiết kế mới cho siêu tụ điện với mức năng lượng riêng 39,3 Wh/kg và mật độ năng lượng 128 kW/kg, gần gấp đôi hiệu năng của các siêu tụ điện thương mại về cả 2 chỉ số.


Để đạt được điều này, nhóm nghiên cứu đã tạo ra một khối bọt có cấu trúc lỗ rỗ chứa các ống nano carbon. Các lỗ hổng nano mang lại một diện tích tiếp xúc lớn để giúp các chất điện phân thấm qua dễ dàng và cho phép nó lưu trữ năng lượng dày đặt hơn so với các thiết kế thông thường.

Khối bọt được tạo ra bằng quy trình lắng đọng hơi hoá học của graphene và các ống nano carbon trên một chất nền bằng niken (Ni) và tiếp tục lắng đọng các hạt nano ruthenium oxide ngậm nước (RuO2), trong đó mỗi hạt có kích thước dưới 5 nm. Bên trong khối bọt, graphene vừa đóng vai trò thu thập dòng điện vừa đóng vai trò là một lớp đệm để dẫn electron và cách ly khối bọt khỏi chất điện phân.

Một trong những ưu thế của siêu tụ điện so với pin thông thường là hiệu suất sạc/xả ưu việt và thiết kế siêu tụ điện của UCR không phải là ngoại lệ. Kỳ lạ hơn, điện dung của nó không chỉ ổn định hơn mà còn thực sự được cải thiện thêm 6% sau 8100 lần sạc/xả. Các nhà nghiên cứu tin rằng sự cải thiện này có được là nhờ tính năng điện hoá của các vật liệu hoạt hoá.

Hiệu năng cao, độ ổn định và dễ chế tạo của hệ thống này khiến nó rất có tiềm năng để sản xuất với số lượng lớn trong tương lai. Và mặc dù năng lượng riêng của nó vẫn chưa thể so sánh với công nghệ pinLi-ion nhưng đây là một bước đi quan trọng để phát triển đúng hướng.

Báo cáo chi tiết về siêu tụ điện của UCR đã vừa được đăng tải trên tạp chí Nature Scientific Reports.

Nguồn: UC Riverside