Tuesday 20 February 2018

Angular - Promises and Observables

Promise
Promises deal with one asynchronous event at a time.
In Angular we can use either Promises or Observables. By default the Angular Http service returns an Observable. To prove this, hover the mouse over the get() method of the Http service in any service.ts file. Notice from the intelligence, that it returns Observable[Response].
 To use Promises instead of Observables we will have to first make a change to the service to return a Promise instead of an Observable.

Observable
Observables can be defined as a streams of data whose items arrive asynchronously over time.
To use observables, Angular uses a third-party library called Reactive Extensions (RxJS). Observables are a proposed feature for ES 2016, the next version of JavaScript.

You can think of an observable as an array whose items arrive asynchronously over time. Observables help you manage asynchronous data, such as data coming from a backend service. Observables are used within Angular itself, including Angular’s event system and its http client service. To use observables, Angular uses a third-party library called Reactive Extensions (RxJS). 

Differences: 
In Angular, to work with asynchronous data we can use either Promises or Observable. There are several differences between Promises and Observables.
  • A Promise emits a single value where as an Observable emits multiple values over a period of time. You can think of an Observable like a stream which emits multiple items over a period of time and the same callback function is called for each item emitted. So with an Observable we can use the same API to handle asynchronous data whether that data is emitted as a single value or multiple values over a period of time.
  • A Promise is not lazy where as an Observable is Lazy. 
  • A Promise cannot be cancelled where as an Observable can be cancelled using the unsubscribe() method.
  • Observable provides operators like map, forEach, filter, reduce, retry, retryWhen etc.

Continue Reading →

Friday 2 February 2018

IList and IEnumerable

In LINQ to query data from collections, we use IEnumerable and IList for data manipulation.IEnumerable is inherited by IList, hence it has all the features of it and except this, it has its own features. IList has below advantage over IEnumerable.

IList

  1. IList exists in System.Collections Namespace.
  2. IList is used to access an element in a specific position/index in a list.
  3. Like IEnumerable, IList is also best to query data from in-memory collections like List, Array etc.
  4. IList is useful when you want to Add or remove items from the list.
  5. IList can find out the no of elements in the collection without iterating the collection.
  6. IList supports deferred execution.
  7. IList doesn't support further filtering.

IEnumerable

  1. IEnumerable exists in System.Collections Namespace.
  2. IEnumerable is a forward only collection, it can't move backward and between the items.
  3. IEnumerable is best to query data from in-memory collections like List, Array etc.
  4. IEnumerable doen't support add or remove items from the list.
  5. Using Ienumerable we can find out the no of elements in the collection after iterating the collection.
  6. IEnumerable supports deferred execution.
  7. IEnumerable supports further filtering.
IEnumerable VS IEnumerator
Both of interfaces help to loop through the collection.

in the case of IEnumerator, we need to invoke the MoveNext method and to retrieve the current item, we need to invoke the current property.

Relation
The IEnumerable interface actually uses IEnumerator. The main reason to create an IEnumerable is to make the syntax shorter and simpler.

If you go to the definition of the IEnumerable<T> interface, you will see this interface has a method GetEnumerator() that returns an IEnumerator object back.

In short, this IEnumerable uses IEnumerator internally.

Differences
The main difference between IEnumerable and IEnumerator is an IEnumerator retains its cursor's current state.


IList and List

IList is an interface and List is concrete class. 
Let's suppose you have a business object where you want to use a object of type Apple. May be it is fine for now but later you may need to support Mango type object. In that case you may probably need to change the business layer. 
To get rid of these tight coupling you need to use interface like IFruit. Then your business layer will not depend just on Apple class and you will get rid of tight coupling. 

Continue Reading →

Topics

ADFS (1) ADO .Net (1) Ajax (1) Angular (43) Angular Js (15) ASP .Net (14) Authentication (4) Azure (3) Breeze.js (1) C# (47) CD (1) CI (2) CloudComputing (2) Coding (7) CQRS (1) CSS (2) Design_Pattern (6) DevOps (4) DI (3) Dotnet (8) DotnetCore (16) Entity Framework (2) ExpressJS (4) Html (4) IIS (1) Javascript (17) Jquery (8) Lamda (3) Linq (11) microservice (3) Mongodb (1) MVC (46) NodeJS (8) React (11) SDLC (1) Sql Server (32) SSIS (3) SSO (1) TypeScript (1) UI (1) UnitTest (1) WCF (14) Web Api (15) Web Service (1) XMl (1)

Dotnet Guru Archives