Less.org

0

Category : ,

Introduced to http://lesscss.org/ by
http://net.tutsplus.com/tutorials/html-css-techniques/build-a-twitter-clone-from-scratch-the-design/

Link to less js file and my local style file.
    
    
    

Build up nesting of styles using Less.
header {
 background: url(gfx/bg-header.png);
 height: 85px;
 width: 100%;
 div.wrapper {
  padding: 11px 0;
  img {
   position: relative;
   top: 10px;
   margin: 0 15px 0 0;
  }
  span {
   font-size: 18px;
   margin: 0 42px 0 0;
  }
  form {
   display: inline;
   input {
    margin: 0 0 0 14px;
   }
  }
  #btnLogOut {
   float: right;
   margin: 14px 0 0 0;
  }
 }
}

Online compiler http://winless.org/online-less-compiler to generate css from less file.

jQuery DataTables

0

Category :

Basic Implementation

Download files from www.datatables.net
Add files to project.
Reference files in master/main page or on specific view.






Initialise table as dataTable.


Also had to add this piece of css to ensure header and footer covered all buttons within.
div.ui-widget-header {
    height: 25px;
}

And that should be about it.

NLog Intro

0

Category :

Basic Setup

Create new config file.
Change the "Copy To Output Directory" option for this file to "Copy always".

Config File




    
      
        
          
          
          
          
          
          
          
        
      
      
    

    
      
      
    

DR



  
    
      
test

Instantiate Logger


private static NLog.Logger _logger = NLog.LogManager.GetCurrentClassLogger();
my thanks to: http://www.codeproject.com/Articles/10631/Introduction-to-NLog

Implementing a Basic Hello World WCF Service

0

Category :

  • A WCF Service is a class library, which defines one or more WCF service interface contracts
  • The System.ServiceModel assembly is referenced by all of the WCF Service projects
  • The implementations of a WCF Service are just regular C# classes
  • A WCF Service must be hosted in a hosting application
  • Visual Studio 2010 has a built-in hosting application for WCF Services, which is called ASP.NET Development Server
  • A client application uses a proxy to communicate with WCF Services
  • A configuration file can be used to specify settings for WCF Services

Endpoint

Imagine that you are trying to send a birthday gift to someone. What information you need? The first and the foremost is the address, where the gift needs to be delivered. And the second one is how wiil the gift be transmitted? By train or bus? And the last one you must know what is the content you are transmitting. What type of goods is it?

The ABC of Windows Communication Foundation

  • "A" - stands for Address: Where is the service?
  • "B" - stands for Binding: How do I talk to the service?
  • "C" - stands for Contract: What can the service do for me?

 http://www.codeproject.com/Articles/97204/Implementing-a-Basic-Hello-World-WCF-Service
http://www.c-sharpcorner.com/UploadFile/rkartikcsharp/abc-of-wcf/

Chrome Developers Tools Overview

0

Category :

Excellent intro article to "The Webkit Inspector" or "Chrome Developers Tools" as I know them....

http://jtaby.com/2012/04/23/modern-web-development-part-1.html

N-Tier Architecture and Tips

0

Category :

Overview

N-Tier architecture is an industry-proved software architecture model, suitable to support enterprise-level client/server applications by resolving issues like scalability, security, fault tolerance and etc. .NET has many tools and features, but .NET doesn’t have pre-defined ways to guard how to implement N-Tier architecture.

N-Tier Architecture Introduction.

Tier and Layer

Firstly we need to clarify the difference between two terms in N-Tier architecture: tier and layer. Tier usually means the physical deployment computer. Usually an individual running server is one tier.
By contrast, layer usually means logic software component group mainly by functionality; layer is used for software development purpose.
Each layer may run in an individual tier. However, multiple layers may also be able to run in one tier.
there's more...

Tier and Process

If a layer can run in an individual process, usually it will also be able to run in an individual computer (tier), hence it can be considered capable for an individual tier in N-Tier architecture. However, this isn’t always true, if there are two layers which are implemented to run in two individual processes but they communicate in a such way that their IPC (inter-process communication) is solely based on a non-distributed way, such as the local shared memory, then these two layers can run in two different processes only in the same computer, not in two different computers.

Layer and Process

A layer may run in an individual process; several layer may also run in an individual process; a layer may run in several processes too. If you read above section “Tier and Layer Relationship”, you can understand here easily.

3-Tier Architecture

The simplest of N-Tier architecture is 3-Tier which typically contains the following software component layers: presentation layer, application layer and data layer, which are depicted below.





A layer can access directly only the public components of its directly-below layer. For example, presentation layer can only access the public components in application layer, but not in data layer. Doing so can minimize the dependencies of one layer on other layers. This dependency minimization will bring benefits for layer development/maintenance, upgrading, scaling and etc. Doing so also makes the tier security enforcement possible. Finally, doing so can also avoid cyclic dependencies among software components.

In order to claim a complete 3-Tier architecture, all three layers should be able to run in separate computers.

These three layers are briefly described as below:
Presentation layer: a layer that users can access directly, such as desktop UI, web page and etc. Also called client.
Application layer: this layer encapsulates the business logic (such as business rules and data validation), domain concept, data access logic and etc. Also called middle layer.
Data layer: the external data source to store the application data, such as database server, CRM system, ERP system, mainframe or other legacy systems and etc. The one we meet often today is database server. For N-Tier architecture, we need to use the non-embedded database server, such as SQL server, Oracle, DB2, MySQL or PostgreSQL. The non-embedded database server can be run in an individual computer. Whereas, the embedded type databases, such as Microsoft access, dbase and etc, cannot run in an individual computer, and then cannot be used as the data layer of the 3-Tier architecture.

1, 2, 3 or More Tier Architecture

1-Tier: all above layers can only run in one computer. In order to achieve 1-Tier, we need to use the embedded database system, which cannot run in an individual process. Otherwise, there will be at least 2-Tier because non-embedded databases usually can run in an individual computer (tier).
2-Tier: either presentation layer and application layer can only run in one computer, or application layer and data layer can only run in one computer. The whole application cannot run in more than 2 computers.
3-Tier: the simplest case of N-Tier architecture; all above three layers are able to run in three separate computers. Practically, these three layers can also be deployed in one computer (3-Tier architecture, but deployed as 1-Tier).
N-Tier: 3 or more tiers architecture. Diagram 2 below depicts a typical N-Tier architecture. Some layers in 3-Tier can be broken further into more layers. These broken layers may be able to run in more tiers. For example, application layer can be broken into business layer, persistence layer or more. Presentation layer can be broken into client layer and client presenter layer. In diagram 2, in order to claim a complete N-Tier architecture, client presenter layer, business layer and data layer should be able to run in three separate computers (tiers). Practically, all these layers can also be deployed in one compute (tier).





Below are brief summaries on all layers in Diagram 2:
Client layer: this layer is involved with users directly. There may be several different types of clients coexisting, such as WPF, Window form, HTML web page and etc.
Client presenter layer: contains the presentation logic needed by clients, such as ASP .NET MVC in IIS web server. Also it adapts different clients to the business layer.
Business layer: handles and encapsulates all of business domains and logics; also called domain layer.
Persistence layer: handles the read/write of the business data to the data layer, also called data access layer (DAL).
Data layer: the external data source, such as a database.

Advantages and Disadvantages of Different Tier Architectures

1 or 2-Tier

Advantages: simple and fast for a lower number of users due to fewer processes and fewer tiers; low cost for hardware, network, maintenance and deployment due to less hardware and network bandwidth needed.
Disadvantages: will have issues when the number of users gets big; as limitation to solve issues like security, scalability, fault tolerance and etc because it can be deployed in only 1 or 2 computes.

N-Tier Architecture

Advantages: the following are general advantages:


loads of dis/advantages and tips can be found on the excellent article this is based on:
http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips


SOLID Principles of Programming

0

Category :

Robert C Martin introduced the acronym SOLID in the early 2000s to communicate five high level principles for object oriented programming. The five principles are:

Single Responsibility – an object should have only one responsibility.

Objects created in this fashion are considered more durable over the long term because they have only one reason to change. Using the single responsibility principle will cause you to have many more classes.
However, the more granular your classes become, the easier it will be to maintain and modify those classes without impacting a large portion of your code.
http://codebetter.com/karlseguin/2008/12/05/get-solid-single-responsibility-principle/

Open/Closed – an object is open for extension, but closed for modification.

This principle is implemented by utilizing the other SOLID principles in conjunction with object oriented development patterns. How do you make modifications, sometimes major modifications, without breaking your existing code? Applying the open/closed principle you would not modify the existing code; rather, through implementing software development patterns, you would add new functionality, taking advantage of the existing software, without changing the way it works internally.
That is the reason that SOLID is an acronym. Each of the principles work hand in hand and cannot stand alone. For example, the Single Responsibility pattern we reviewed yesterday provides a framework for Open/Closed. If each object has a single responsibility, it is a lot easier to lock them down (Close) while still adding new functionality at a later time (open).
If you would like to see an example of code techniques implementing Open/Closed, I found a great article in MSDN magazine by Jeremy Miller, http://msdn.microsoft.com/en-us/magazine/cc546578.aspx, from 2008 demonstrating how the SOLID principles may be implemented through different object oriented patterns.

Liskov Substitution – An object should be replaceable with instances of a subtype without altering the correctness of a program.

Liskov postures that your specific class implementations should utilize an abstract implementation of external objects. In so doing, you can change the functionality of that class by substituting a different implementation of the abstract external object with another, and the containing class need not be modified in any way. In essence, this is one technique for fulfilling the Open/Closed principle.
an object called BusinessProcess. BusinessProcess requires interaction with a data source. Rather than instantiating a specific data source the BusinessProcess class utilizes an IDataSource interface. By using an interface the BusinessProcess object works with any implementation of the IDataSource interface.
The IDataSource interface can be implemented by an XML data store. Later it may be implemented with a relational database data store without modifying the BusinessProcess class in any manner.
In this fashion, Single Responsibility, Open/Closed and Liskov Substitution work together resulting in code that may be easily extended with the least impact to existing code. Utilizing other software development patterns, new implementations of IDataSource may be created, instantiated, and inserted into the program for execution by adding only new code, and modifying configuration data for implementation.

Interface Segregation – segregated interfaces are better than on single general purpose interface.

Unlike the other principles we have covered up to this point, Single Responsibility, Open/Closed, and Liskov Substitution, the Interface Segregation Principle is less transferable to languages that are not object oriented.
If I were to summarize the principle into one sentence it would be, “it is better to have more tightly defined interfaces rather than fewer comprehensive interfaces.”.
A rule of thumb might be, if you can foresee a realistic potential for the need to separate an interface into smaller interfaces because the interface contains features that do not apply to all implementations, then it makes sense to break it out.
This is where refactoring comes into play. Perhaps your interface was too general when you started out. That doesn’t mean you can’t break the interface out into smaller more granular interfaces at a later date. It just takes more work; especially if you don’t have automated unit tests to prove your refactoring work hasn’t broken your business requirements.

Dependency Inversion = Base your code on abstractions such rather than concrete implementations.

If your class dependencies are based on abstractions (Interface or abstract class) then the classes implementing the abstractions may be replaced without impacting any and every consumer.
Dependency Injection is a good implementation of the Dependency Inversion Principle. Using Dependency Injection, a consumer passes a desired kind of implementation to a class capable of resolving the correct implementation required, returning the correct object. container i guess.
One of my favorite examples is having a web app that can save data to a web service, an XML File, or a relational database. The user says, Save to XML. The web application knows nothing about how to save XML; but it knows how to call a persistence controller that returns a class that will save the data as an XML file. The Class supporting XML is based on an interface shared by the web application. The Web site, in this instance is injecting through a controller, the information necessary to implement the correct type of Class to persist the data to XML.
Dependency Injection is one technique of implementing Dependency Inversion. They are not equivalent concepts.


my thanks to: http://www.sswug.org/nlarchive.aspx
first email newsletter received on 30/07/2012

Code First Approach using EF, IoC, Unity Framework, Repository and UoW Patterns, and MVC Razor View.

0

Category :

Architectural Overview

CodeFirstData layer (DAL)

The data layer is the class library defining a layer which is responsible for interacting with database, contains context classes and a factory pattern implementation to interact with database. The layer contains the repository for each entity to map with database, thus making a complete ORM (Object Resource Model) solution.

CodeFirstEntities layer (POCO Model)

Entity layer acts as a model to MVC application, and is also responsible for the creation of DataBase objects when the dbset is first executed. It contains Entity classes in POCO form, having relations and data annotations(Rules/Constraints to be put on Database table/columns).

CodeFirstServices layer (BLL)

The layer contains services which uses repositories to fetch data from database. The interaction between Services and Repositories is kept loosely coupled thus implementing Inversion of Control using Dependency Injection. Its "constructor based" dependency injection does not allow service to make direct instance of our repositories. Service layer acts as an interface between controllers and repositories, passes request of controller to repositories.

Service Layer defines an application's scope and its available set of operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations.

IOC and DI

Dependency Injection is an important component in my application. All the services are required to be late bound with Model layer with Dependency Injection. In addition, the IoC container manages the lifetime of service objects. For example the Context object. I set lifetime type as PerThreadLifetimeManager in Unity configuration. This makes one and only one context object created in a single request and the different request has a different context object. Another thing I want to mention is ASP.NET MVC3 has its own way to provide Dependency Inject for controller via implementing DependencyResolver interface. The IoC container I used in the demo is Unity.

Container

The "Container" or "IOC Container" is the main object that is used to create objects and inject dependencies into them. Whenever you want an object to be open to IoC, you have to use the container to create the instance using container.Resolve<T>() method instead of the "new" keyword.

my thanks to: http://dotnetslackers.com/articles/aspnet/Code-First-Approach-using-Entity-Framework-4.aspx

IQueryable vs IEnumerable vs IList

0

Category :

IEnumerable - When you to deal with in process memory object collections and loop through the collection objects.

IQueryable - When you have to run ad-hoc queries against datasource like LINQ to SQL Server Entity Framework and other sources which implemented IQueryable.

IList - Add, remove or refer to an item by index.


my thanks to: http://www.youtube.com/watch?v=oiFPblrire8&feature=plcp

Inversion of Control/Dependency Injection

0

Category :

Dependency injection is also known as “Inversion of Control,” as originally described by Robert Martin.  Interestingly enough, the development community typically uses the phrase “dependency injection” when talking about the technique itself and “IoC” when talking about dependency injection containers. But rest assured, there is no difference whatsoever between “Dependency Injection” and “Inversion of Control (IoC).”

Dependency Injection - Enables loosely coupled/dependent apps.
You inject a class's dependencies into it, through a constructor or a series of setters, rather than instantiating them in the class. It can be done WITHOUT an IoC container.

Tightly/Highly Coupled Dependencies

HomeController is tightly coupled/dependent on the Employee class, without the Employee class its not much use...
public class HomeController : Controller
{
    public ActionResult Index()
    {
        Employee employee = new Employee();

        return View();
    }
}
Still tightly coupled to the Employee class...
public class HomeController : Controller
{
    private readonly Employee _emp;

    public HomeController(Employee emp)
    {
        this._emp = emp;
    }

    public ActionResult Index()
    {
        ViewBag.Message = _emp.GetName();

        return View();
    }
}

Loosely Coupled Dependencies

Using an Interface allows us to pass any object that implments this Interface, this allows us to pass fake objects which makes Testing easier...
public class HomeController : Controller
{
    private readonly IEmployee _emp;

    public HomeController(IEmployee emp)
    {
        this._emp = emp;
    }

    public ActionResult Index()
    {
        ViewBag.Message = _emp.GetName();

        return View();
    }
}
There are three main styles of dependency injection

Constructor injection.

Passing an object's dependencies to its constructor.
examples above

Setter injection.

Dependencies are set onto public properties exposed by the object in need. Dont need to modify the constructor of a legacy class.
Allows expensive resources or services to be created as late as possible and only when needed.
Should be used sparingly in place of Constructor Injection, because it:
Does not make it clear to the developer which dependencies are needed when, at least until a "has not been initialized" exception is thrown.
Makes it a bit more difficult to track down where the exception came from and why it got thrown.

Interface injection.

seems to be very similar to Controller Injection above, good description, http://www.martinfowler.com/articles/injection.html
The third injection technique is to define and use interfaces for the injection. With this technique you define an interface that you use to perform the injection through. This configuration has two stages, registering components through lookup keys is pretty similar to the other examples. A new step is to register the injectors that will inject the dependent components. Each injection interface needs some code to inject the dependent object.

Injection Options (Injectors)

The next logical question is, what actually creates the dependencies that are to be injected into "injectees"? There are two appropriate places for adding creation logic: controllers and containers.

Manual Injection/DI Controllers

This requires the HomeController to be instantiated somewhere and dependencies supplied using constructor injection, which I presume is not  an easy option with MVC.
Regardless of what you use as your controller, the controller is an appropriate location for performing Dependency Injection "wiring". This is where concrete objects are created and injected as dependencies.

Automatic Injection/DI Container

Inversion-of-Control/Dependency-Injection "Containers" can be used to watch an application and inject dependencies whenever a particular event occurs. For example, whenever a HomeController instance is created, it automatically gets injected with its needed dependencies.

Dependency injection involves at least three elements:

1) a dependent consumer - HomeController
2) a declaration of a component's dependencies, defined as interface contracts - Constructor
3) an injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interface on request - IoC container/manually.

Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.
One simple example of IoC is JUnit, the framework code calls setUp and tearDown methods for you to create and clean up your text fixture. It does the calling, your code reacts/implements the creation and clean up - so again control is inverted.

Inversion of Control Containers

For this new breed of IoC containers the inversion is about how they lookup a plugin(IEmployee) implementation. The approach that these containers use is to ensure that any user of a plugin follows some convention(an interface) that allows a separate assembler module to inject the implementation into the lister(HomeController).
As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.
There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.

Using a Service Locator

The key benefit of a Dependency Injector is that it removes the dependency that the HomeController class has on the concrete Employee implementation. Injection isn't the only way to break this dependency, another is to use a service locator.
The basic idea behind a service locator is to have an object that knows how to get hold of all of the services that an application might need, needs to be investigated further...

Service Locator vs Dependency Injection

The fundamental choice is between Service Locator and Dependency Injection. The first point is that both implementations provide the fundamental decoupling that's missing in the naive example - in both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.


my thanks to:
http://www.martinfowler.com/articles/injection.html http://en.wikipedia.org/wiki/Dependency_injection
http://www.codeproject.com/Articles/13831/Dependency-Injection-for-Loose-Coupling
http://devlicious.com/blogs/billy_mccafferty/archive/2009/11/09/dependency-injection-101.aspx

Design Pattern - Unit of Work

0

Category :

Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.
http://martinfowler.com/eaaCatalog/unitOfWork.html

Basically unit of work is transaction management. Within one transaction, we may pull data from database, make some changes, add new record, etc.

There are some important notes about unit of work and web application:
1. Unit of work should be unique for each request, i.e. unit of work cannot share between requests.
2. Unit of work should be share within one request, i.e. if you use unit of work from your controller and other places, that unit of work object should be the same if it is within one request.

Dependency Injection comes to rescue to make sure the above requirements are met. Dependency Injection provides life time management and resolving the dependencies. For our case, unit of work object's life time must be per request.

http://sdesmedt.wordpress.com/2009/02/18/unit-of-work-pattern/



my thanks to: http://jittuu.com/2012/2/9/UnitOfWork-pattern-and-asp.net-mvc/

Understanding Hash Functions and Keeping Passwords Safe

0

Category :

Understanding Hash Functions and Keeping Passwords Safe

From time to time, servers and databases are stolen or compromised. With this in mind, it is important to ensure that some crucial user data, such as passwords, can not be recovered.

What Does “Hashing” Do?
Hashing converts a piece of data (either small or large), into a relatively short piece of data such as a string or an integer.
This is accomplished by using a one-way hash function. “One-way” means that it is very difficult (or practically impossible) to reverse it.

MD5
With md5(), the result will always be a 32 character long string. You may md5() much longer strings and data, and you will still end up with a hash of this length.

Using a Hash Function for Storing Passwords
The usual process during a user registration:
    User fills out registration form, including the password field.
    The web script stores all of the information into a database.
    However, the password is run through a hash function, before being stored.
    The original version of the password has not been stored anywhere, so it is technically discarded.

And the login process:
    User enters username (or e-mail) and password.
    The script runs the password through the same hashing function.
    The script finds the user record from the database, and reads the stored hashed password.
    Both of these values are compared, and the access is granted if they match.

Problem #1: Hash Collision
A hash “collision” occurs when two different data inputs generate the same resulting hash. The likelihood of this happening depends on which function you use. We can figure out another password that will convert to the same hash value, with a simple script.

So we need a hash function that has a very big range.
For example, md5() might be suitable, as it generates 128-bit hashes. This translates into 340,282,366,920,938,463,463,374,607,431,768,211,456 possible outcomes.

Sha1
Sha1() is a better alternative, and it generates an even longer 160-bit hash value.

Problem #2: Rainbow Tables
A rainbow table is built by calculating the hash values of commonly used words and their combinations. For example, you can go through a dictionary, and generate hash values for every word.

How can this be prevented?
We can try adding a “salt”. What we basically do is concatenate the “salt” string with the passwords before hashing them. The resulting string obviously will not be on any pre-built rainbow table. But, we’re still not safe just yet!

Problem #3: Rainbow Tables (again)
Even if a salt was used, this may have been stolen along with the database. All they have to do is generate a new Rainbow Table from scratch, but this time they concatenate the salt to every word that they are putting in the table.

How can this be prevented?
We can use a “unique salt” instead, which changes for each user.

Problem #4: Hash Speed
Most hashing functions have been designed with speed in mind, because they are often used to calculate checksum values for large data sets and files, to check for data integrity.
An 8 character long string has 62^8 possible versions. That is a little over 218 trillion. At a rate of 1 billion hashes per second, that can be solved in about 60 hours.
And for 6 character long passwords, which is also quite common, it would take under 1 minute.

How can this be prevented?
Imagine that you use a hash function that can only run 1 million times per second on the same hardware, instead of 1 billion times per second. It would then take the attacker 1000 times longer to brute force a hash. 60 hours would turn into nearly 7 years!

Or you may use an algorithm that supports a "cost parameter," such as BLOWFISH. In PHP, this can be done using the crypt() function.

thanks.credit to:
http://net.tutsplus.com/tutorials/php/understanding-hash-functions-and-keeping-passwords-safe/

Entity Framework - Intro

0

Category :

When you use EF it by default loads each entity only once per context. The first query creates entity instace and stores it internally. Any subsequent query which requires entity with the same key returns this stored instance. If values in the data store changed you still receive the entity with values from the initial query. This is called Identity map pattern. You can force the object context to reload the entity but it will reload a single shared instance.

Any changes made to the entity are not persisted until you call SaveChanges on the context. You can do changes in multiple entities and store them at once. This is called Unit of Work pattern. You can't selectively say which modified attached entity you want to save.

Combine these two patterns and you will see some interesting effects. You have only one instance of entity for the whole application. Any changes to the entity affect the whole application even if changes are not yet persisted (commited). In the most times this is not what you want.

You can always think about context as about Unit of work. Create context when you open Edit dialog, load data for editation, modify data, save changes, close context. In server scenario it depends on situation. Sometimes it is enough to have context in single method but if you want to make multiple operations working with data you can share the context among multiple methods. Again - unit of work. Things which should be handled together should use single context.




refs
http://stackoverflow.com/questions/3653009/entity-framework-and-connection-pooling/3653392#3653392
http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

Inheritance with EF (compares 3 techniques)

http://weblogs.asp.net/manavi/archive/2010/12/24/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph.aspx

Bitwise operations

0

Category :

Bitwise operations........some craic!!
----------------------

int test1 = 3; // binary: 0011
int test2 = 2 // binary: 0010
int flagTest = test1 | test2; // binary result: 0011 | 0010 = 0011

0011
0010 OR
----
0011

flagTest = 8; // 1000
flagTest |= 3; // 2 = 0011
// flagTest is now binary 1011

AutoApprovalFails fails = AutoApprovalFails.Success;

// this ngb/coach level is disabled
fails |= AutoApprovalFails.HasTutorsInTraining;

fails |= AutoApprovalFails.InvalidCourseLevel;

string message = string.Empty;
foreach (Enum value in Enum.GetValues(typeof(AutoApprovalFails)))
{
    // eg, if 0100 in 1110;  0100 & 0111 = 0100
    if (((AutoApprovalFails)value & fails) == (AutoApprovalFails)value)
    {
        message += EnumDescriptor.GetDescription((AutoApprovalFails)value);
    }
}