Implementing Continuous Scrolling UI Pattern in ASP.NET

When you have numerous records to show, we have to resort to Paging. There is a better alternative to display voluminous data (especially read only data) while providing a better user experience & also making efficient use of server bandwidth - the Continuous Scrolling or Infinite Scrolling UI Pattern. Read on to know more about how to implement Continuous Scrolling UI Pattern in ASP.NET with a GridView.

More Related Resource Links

The singleton pattern is one of the best-known patterns in software engineering. Essentially, a singleton is a class which only allows a single instance of itself to be created, and usually gives simple access to that instance. Most commonly, singletons don't allow any parameters to be specified when creating the instance - as otherwise a second request for an instance but with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter, the factory pattern is more appropriate.) This article deals only with the situation where no parameters are required. Typically a requirement of singletons is that they are created lazily - i.e. that the instance isn't created until it is first needed.

The ViewModel/MVVM pattern continues to gain popularity, with a blog post showing up every so often, and with tweets and retweets popping up even more often :-). At the same time, there are some interesting topics beyond the core pattern that continue to fuel experimentation. A big one amongst those is how should applications use dialogs when using the view model pattern.

The crux of the problem is the desire to keep the view model independent of UI concerns, and ensure it can be tested in a standalone manner, but that often comes to odds when you want the view model to launch a dialog, and/or do some work after the dialog is closed.

The decorator pattern provides a formal way to add new functionality to an existing type, without sub-classing. First question: What is wrong with classical inheritance? In and of itself, nothing is wrong with the good old Is-A relationship. It is very common to derive a new class from an existing base class in order to override a few virtual members, and add a pinch of new functionality.

The job of the Factory design pattern is to create concrete sub classes. You can see the Factory design pattern used throughout the .NET Framework.

The essence of the Factory Pattern is to "Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses." Factory methods encapsulate the creation of objects. This can be useful if the creation process is very complex, for example if it depends on settings in configuration files or on user input.

When we want to make a only one instance of a class and also making sure that there is a global access point to that object then the design pattern we user is called Singleton. The pattern ensures that the class is instantiated only once and that all requests are directed to that one and only object.

Software architects generally think in terms of high-level abstractions rather than low-level programming details. Representing a system in terms of high-level abstractions promotes understanding of the system and reduces its perceived complexity. One such set of abstractions is software design patterns. They have been successfully applied in the past to simplify and solve recurring problems in software design.

An abstract factory provides an interface for creating families of related objects without specifying their concrete classes. Sometimes one wants to construct an instance of one of a suite of classes, deciding between the classes at the time of instantiation. In order to avoid duplicating the decision making everywhere an instance is created, we need a mechanism for creating instances of related classes without necessarily knowing which will be instantiated.

The Prototype Pattern approaches the creation of the objects that our client will use by cloning instances from prototypes as required. This achieves the general aim of decoupling the client from the objects that it will use, but also adds some advantages unique to the Prototype pattern.

The Factory pattern allowed us to decouple our client from an object which it uses. The Abstract Factory pattern extends this idea to manage separate families of objects.

A runtime selection, or configuration option, in our client could decide which family of objects is to be used. The Abstract Factory pattern allows us to write generic code to instantiate and use the family objects regardless of which family is chosen at runtime. The pattern also helps us enforce a rule where objects from just the chosen family are used uniformly by the client.

The Singleton pattern is a specialist creational pattern as it's primary focus is to facilitate a single shared instance of our object rather than to decouple our client from the object's implementation as with the other creational patterns.

Numerous design patterns exist in the software world today, and ultimately nothing is preventing you from making your own (if people buy into it or not is another question). Furthermore, there is no 'master list' of patterns that all developers agree upon. While this is true, if you pick up any book on the subject, you will find a set of very common patterns most programmers agree are very useful. Many of these patterns were first formalized in the seminal book on the subject, Design Patterns: Elements of Reusable Object-Oriented Software (aka, the Gang of Four [GOF] book; not to be confused with the UK punk band of the same name).

The State Pattern is a behavioral pattern that can be used to alter the behavior of an object at run time. As the state of an object changes, the functionality of the object can change drastically. This change of behavior is hidden from the Client and the Client interfaces with a wrapper object known as the Context. The State Pattern is a dynamic version of the Strategy Pattern.