Angular Promise vs Observable


A Promise handles a single event when an async operation completes or fails.

Note: There are Promise libraries out there that support cancellation, but ES6 Promise doesn’t so far.


An Observable is like a Stream (in many languages) and allows to pass zero or more events where the callback is called for each event.

Often Observable is preferred over Promise because it provides the features of Promise and more. With Observable it doesn’t matter if you want to handle 0, 1, or multiple events. You can utilize the same API in each case.

Observable also has the advantage over Promise to be cancelable. If the result of an HTTP request to a server or some other expensive async operation isn’t needed anymore, the Subscription of an Observable allows to cancel the subscription, while a Promise will eventually call the success or failed callback even when you don’t need the notification or the result it provides anymore.

Observable provides operators like map, forEach, reduce, … similar to an array

There are also powerful operators like retry(), or replay(), … that are often quite handy.


Taking advantage of Observables in Angular




Stub EF

If you want to use TDD (or any other testing approach with high test coverage) and EF together you must write integration or end-to-end tests. The problem here is that any approach with mocking either context or repository just creates test which can test your upper layer logic (which uses those mocks) but not your application.

Simple example:

Let’s define generic repository:

public interface IGenericRepository<TEntity> 
    IQueryable<TEntity> GetQuery();

And lets write some business method:

public IEnumerable<MyEntity> DoSomethingImportant()
    var data = MyEntityRepo.GetQuery().Select((e, i) => e);

Now if you mock the repository you will use Linq-To-Objects and you will have a green test but if you run the application with Linq-To-Entities you will get an exception because select overload with indexes is not supported in L2E.

This was simple example but same can happen with using methods in queries and other common mistakes. Moreover this also affects methods like Add, Update, Delete usually exposed on repository. If you don’t write a mock which will exactly simulate behavior of EF context and referential integrity you will not test your implementation.

Another part of story are problems with Lazy loading which can also hardly be detected with unit tests against mocks.

Because of that you should also introduce integration or end-to-end tests which will work against real database using real EF context ane L2E. Btw. using end-to-end tests is required to use TDD correctly. For writing end-to-end tests in ASP.NET MVC you can WatiN and possibly also SpecFlow for BDD but this will really add a lot of work but you will have your application really tested. If you want to read more about TDD I recommend this book (the only disadvantage is that examples are in Java).

Integration tests make sense if you don’t use generic repository and you hide your queries in some class which will not expose IQueryable but returns directly data.


public interface IMyEntityRepository
    MyEntity GetById(int id);
    MyEntity GetByName(string name); 

Now you can just write integration test to test implementation of this repository because queries are hidden in this class and not exposed to upper layers. But this type of repository is somehow considered as old implementation used with stored procedures. You will lose a lot of ORM features with this implementation or you will have to do a lot of additional work – for example add specification pattern to be able to define query in upper layer.

In ASP.NET MVC you can partially replace end-to-end tests with integration tests on controller level.

Edit based on comment:

I don’t say that you need unit tests, integration tests and end-to-end tests. I say that making tested applications require much more effort. The amount and types of needed tests is dependent on the complexity of your application, expected future of the application, your skills and skills of other team members.

Small straighforward projects can be created without tests at all (ok, it is not a good idea but we all did it and at the end it worked) but once a project passes some treshold you can find that introducing new features or maintaining the project is very hard because you are never sure if it breaks something which already worked – that is called regression. The best defence against regression is good set of automated tests.

  • Unit tests help you to test method. Such tests should ideally cover all execution paths in the method. These tests should be very short and easy to write – to complicated part can be to set up dependencies (mocks, faktes, stubs).
  • Integration tests help you to test functionality accross multiple layers and usually accross multiple processes (application, database). You don’t need to have them for everything, it is more about experience to select where they are helpful.
  • End-to-end tests are something like validation of use case / user story / feature. They should cover whole flow of the requirement.

It is not needed to test a feture multiple times – if you know that the feature is tested in end-to-end test you don’t need to write integration test for the same code. Also if you know that method has only single execution path which is covered by integration test you don’t need to write unit test for it. This works much better with TDD approach where you start with a big test (end-to-end or integration) and go deeper to unit tests.

Depending on your developement approach you don’t have to start with multiple types of test from beginning but you can introduce them later as your application will become more complex. The exception is TDD/BDD where you should start to use at least end-to-end and unit tests before you even write single line of other code.

So you are asking the wrong question. The question is not what is simpler? The question is what will help you at the end and what complexity fits your application? If you want to have easily unit tested application and business logic you should wrap EF code to some other classes which can be mocked. But in the same time you must introduce other type of tests to ensure that EF code works.

I can’t say you what approach will fit your environment / project / team / etc. But I can explain example from my past project:

I worked on the project for about 5-6 months with two collegues. The project was based on ASP.NET MVC 2 + jQuery + EFv4 and it was developed in incremental and iterative way. It had a lot of complicated business logic and a lot of complicated database queries. We started with generic repositories and high code coverage with unit tests + integration tests to validate mapping (simple tests for inserting, deleting, updating and selecting entity). After few months we found that our approach doesn’t work. We had more then 1.200 unit tests, code coverage about 60% (that is not very good) and a lot of regression problems. Changing anything in EF model could introduce unexpected problems in parts which were not touched for several weeks. We found that we are missing integration tests or end-to-end tests for our application logic. The same conclusion was made on a parallel team worked on another project and using integration tests was considered as recommendation for new projects.

source: ASP.NET MVC3 and Entity Framework Code first architecture

Looks like the repository pattern is solution for everything … Repository is not a silver bullet!

I’m using the repository pattern with EF everyday because when I started my current project several months ago it looked like recommended solution. My conclusions:

  • Repository makes interaction with EF much harder. Just browse questions related to EF tags and you will see what complexities must be handled directly on the context, changetracker, etc.
  • Generic repository is something that works for CRUD operations but not for real DDD scenarios. Once your repository works with aggregate roots (DDD) generic approach fails.
  • Unit testing doesn’t work at all because general idea that you will mock repository and test your upper layer without dependencies to EF and database fails once you expose IQueryable. Linq-to-entities is only subset of Linq-to-objects and mock doesn’t handle referential integrity so many times I saw green unit tests and runtime exceptions. The correct testing approach with EF are integration tests. Mocking repository is only for testing real business logic not related to data access. If you don’t have integration test for your business method accessing or persisting data you didn’t test it.
  • Exposing specialized methods like GetByXXX is just step back. Most of these methods are used only once. You will end with the code similar to repositories used for wrapping stored procedures calls. Many developers like ORM just because they can avoid such rigid architecture.

EF itself already offers repository pattern – DbSet and ObjectSet are repositories and DbContext and ObjectContext are Unit of works. So in my opinion repository pattern is overused. It can be useful in large projects where you need strict layering or in case of placing additional logic to its methods. Using repository just because you want to wrap access to EF is often valueless code and just additional layer of complexity.

You can in the same way create reusable methods defining your queries

source: repository pattern

How to work with the Bootstrap DropDown in AngularJS

MyApp.controller(‘SubjectDropDownController’, function ($scope) {

$scope.subjects = [‘Math’, ‘Physics’, ‘Chemistry’, ‘Hindi’, ‘English’];


$scope.dropboxitemselected = function (item) {

$scope.selectedItem = item;




And the drop down can be modified to bind the selected item as shown in the listing below:

LINQ: Case insensitive group on multiple columns

You can pass StringComparer.InvariantCultureIgnoreCase to the GroupBy extension method.

var result = source.GroupBy(a => new { a.Column1, a.Column2 }, 

Or you can use ToUpperInvariant on each field as suggested by Hamlet Hakobyan on comment. I recommend ToUpperInvariant or ToUpper rather than ToLower or ToLowerInvariant because it is optimized for programmatic comparison purpose.

The type arguments for method ‘System.Linq.Enumerable.GroupBy(System.Collections.Generic.IEnumerable, System.Func, System.Collections.Generic.IEqualityComparer)’ cannot be inferred from the usage. Try specifying the type arguments explicitly.

To make it work, I found it easiest and clearest to define a new class to store my key columns (GroupKey), then a separate class that implements IEqualityComparer (KeyComparer). I can then call

var result= source.GroupBy(r => new GroupKey(r), new KeyComparer());

The KeyComparer class does compare the strings with the InvariantCultureIgnoreCase comparer, so kudos to NaveenBhat for pointing me in the right direction.

Simplified versions of my classes:

private class GroupKey
    public string Column1{ get; set; }
    public string Column2{ get; set; }

    public GroupKey(SourceObject r) {
        this.Column1 = r.Column1;
        this.Column2 = r.Column2;

private class KeyComparer: IEqualityComparer<GroupKey>

    bool IEqualityComparer<GroupKey>.Equals(GroupKey x, GroupKey y)
        if (!x.Column1.Equals(y.Column1,StringComparer.InvariantCultureIgnoreCase) return false;
        if (!x.Column2.Equals(y.Column2,StringComparer.InvariantCultureIgnoreCase) return false;
        return true;
        //my actual code is more complex than this, more columns to compare
        //and handles null strings, but you get the idea.

    int IEqualityComparer<GroupKey>.GetHashCode(GroupKey obj)
        return 0.GetHashCode() ; // forces calling Equals
        //Note, it would be more efficient to do something like
        //string hcode = Column1.ToLower() + Column2.ToLower();
        //return hcode.GetHashCode();
        //but my object is more complex than this simplified example


Source: stackoverflow

Gets the Description attribute from an Enum

public static class EnumEx
    public static T GetValueFromDescription<T>(string description)
        var type = typeof(T);
        if(!type.IsEnum) throw new InvalidOperationException();
        foreach(var field in type.GetFields())
            var attribute = Attribute.GetCustomAttribute(field,
                typeof(DescriptionAttribute)) as DescriptionAttribute;
            if(attribute != null)
                if(attribute.Description == description)
                    return (T)field.GetValue(null);
                if(field.Name == description)
                    return (T)field.GetValue(null);
        throw new ArgumentException("Not found.", "description");
        // or return default(T);


var panda = EnumEx.GetValueFromDescription<Animal>("Giant Panda");

source: stackoverflow

Func vs. Action vs. Predicate Delegates

  • Predicate: essentially Func<T, bool>; asks the question “does the specified argument satisfy the condition represented by the delegate?” Used in things like List.FindAll.
  • Action: Perform an action given the arguments. Very general purpose. Not used much in LINQ as it implies side-effects, basically.
  • Func: Used extensively in LINQ, usually to transform the argument, e.g. by projecting a complex structure to one property.

Other important delegates:

  • EventHandler/EventHandler<T>: Used all over WinForms
  • Comparison<T>: Like IComparer<T> but in delegate form.


The difference between Func and Action is simply whether you want the delegate to return a value (use Func) or not (use Action).

Func is probably most commonly used in LINQ – for example in projections:

 list.Select(x => x.SomeProperty)

or filtering:

 list.Where(x => x.SomeValue == someOtherValue)

or key selection:

 list.Join(otherList, x => x.FirstKey, y => y.SecondKey, ...)

Action is more commonly used for things like List<T>.ForEach: execute the given action for each item in the list. I use this less often than Func, although I do sometimes use the parameterless version for things like Control.BeginInvoke and Dispatcher.BeginInvoke.

Predicate is just a special cased Func<T, bool> really, introduced before all of the Func and most of the Action delegates came along. I suspect that if we’d already had Func and Action in their various guises, Predicate wouldn’t have been introduced… although it does impart a certain meaning to the use of the delegate, whereas Func and Action are used for widely disparate purposes.

Predicate is mostly used in List<T> for methods like FindAll and RemoveAll.


source: stackoverflow