“N-tiers” Application

What is meant by “N-tiers”

The N in “n tiers” refers to the number of tiers. A very common value for “N” is 3 (in  figure 1) comprised of three tiers of user interface or presentation, business logic and data access logic when applications behavior is split among multiple tiers these tiers are said to be logically separated. In some cases the separate tiers are physically deployed to different devices or process boundaries on the same device in which case there is physically separated as well. Is not required for separate layers to be deployed separately but they may be, likewise it’s not required that the separate layers be developed independently of one another this approach means it's possible for this to take place in this way you can allow for larger teams to work together concurrently or to have multiple teams working on separate parts of large application.

Generally tiers and layers are used interchangeably from one another however, sometimes use one has a more specific meaning in the case of layers often used to apply specifically to a logical structure of the application, likewise the tiers of an application frequently are used to refer to just the physical structure of the system architecture or infrastructure. In many cases you can refer to an application as N-tier application even if it is only deployed to a single machine and it’s also not uncommon to talk about the different layers of an application when in fact these layers are deployed to different physical tiers.

Logical vs. Physical separation

 The logical separation of concerns is expressed in the source code of the application the code organization and design should reflect the layers that are in use at a minimum individual classes should not include responsibilities that correspond to separate layers and typically each layer will have its own namespace assembly and project in the solution. The logical separation of an application across layer boundaries represents a software design patterns. The physical separation of the application generally refers how it’s deployed. It’s possible  to have logically separated applications  that is physically deployed to a single location, for instance web application with separate assemblies for business logic and data access all  of which deployed of the same “/bin ” folder on a single Web server. However it’s possible to separate these assemblies and deploy them to different physical locations whether on a single device or on separate machines the physical separation of the application across process boundaries and/or devices represents software architecture decisions. Generally the physical separation and the logical separation are described together. In other words you should have a logical separation in your software if you are foreseeing the need to have physical separation in your deployment.

Common mistakes to avoid when designing n-tiers applications

      1.     Tight coupling

Designing your applications in tightly coupled way with in mind that will not evolve.

      2.     Assuming Static Requirements 

Making an assumption that requirements will remain static especially when considering the client as trusted and the mid-tier service assumes the client will be implemented using a particular technology. 

      3.     Mishandled Concurrency

Designing your applications with optimistic concurrency as a choice

      4.     Stateful services 

Keeping context around across multiple service calls.

      5.     Two Tiers Pretending to be Three

 Trying to expose the database directly to the client without  the  mid-tier 

       6.     Undervaluing simplicity 

How to create the most carefully, multi-tier fully separated, re-validating, super design that you come up with. This latest mistake will take you away from the most important goal which is delivering value to your users.  All what you  need is to fix  your goals  and consider whether you are going to need n-tier requires, in other words apply the KISS principle  will always be great thing.

Why should you not use Entity Framework or an ORM?

Entity Framework is it's not a panacea nor is appropriate for every kind of application even an application that heavily uses data just because it's relatively shiny and new and heap doesn't mean you should carefully think about how and whether to fit into the architecture of an application.

·         Isn’t appropriate for every kind of application. EF heavily uses  reflection  and hurts performance. For this  point there are many lightweight  ORM's  that  can be used  as an alternative  such as Dapper.

·       EF doesn't do bulk inserts. It's usually better to use the databases support for this kind of large fast data imports instead or even use some of the native .net features for the task.

Why you should use entity Framework?
Some of the reasons to use entity framework   are:
• Part of the .NET Framework and integrated into Visual Studio ,  that’s  means that is easy to integrate into  your application  you  haven’t to install anything  else. It’s also means that Entity Framework it’s widely used which guaranties timely bug fixes and  innovations and that really evidenced by rich  feature additions that were included with version 5.0 and 6.0.
• Use  LINQ as the primary  query language ,which let you write query  directly  in the programming language against the entity objects  the code that you write as a benefit of IntelliSense and strong typing and compile  time  checking this  far better  than including strings a  SQL or another query  language within your code  .  Entity Framework remove  and LINQ remove all  of the database details from your  main  application code.
• Independent of  the  data source that  used to persist data it manages all  of the  interactions  with the data store.
• The  most important reason  it’s that  Microsoft has made a firm commitment to make  Entity Framework it’s data access  strategy  for foreseeable future .Starting  from   version 6 ,Entity Framework  is an open source project even  if it’s always supported   by the Entity Framework Team .This  has  a lot of advantages such as public  collaboration, auditability  , new features and a lot of refinements that make entity framework even more usable and useful for data applications.
for further  information please take a look at this  link  

Some hints to help you during C# interview

Reference Vs Value types

As for many   the idea of reference type is stored on the heap and the value type is on the stack is completely wrong otherwise will be called Heap types and stack types.   

·         Mainly the difference is about copying. The Assignment of a reference type variable copies a reference   to the object but not the object itself.  This differs from the variables that are based on value types which contains directly the values. 

·         From Eric  Lippert Article   :

"in the Microsoft implementation of C# on the desktop CLR, value types are stored on the stack when the value is a local variable or temporary that is not a closed-over local variable of a lambda or anonymous method, and the method body is not an iterator block, and the jitter chooses to not enregister the value."

•  The choice of allocation mechanism has to do only with the known required lifetime of the storage.

Deep vs Shallow copy

  Shallow copy

•  Field  is a value type a bit-by-bit copy  of the field is performed
•  Field is a reference type the reference is copied but the referred object is not therefore the original object and its clone refer to the same object.     

         The method used by default to make a shallow copy is Object.MemberwiseClone (). 

  Deep copy  

•   Creates a new object and then copying the nonstatic fields (value type or reference type) of the current object to the new object. 

What is an interface?
Interface is contract defined as an abstract type that contains no data or code but defines behaviors as method signatures.

Abstract Vs Interface

The concept of Interfaces and abstract classes is a bit confusing for beginners

•    When you  create an  interface you are creating a definition  that  can never  change  after the interface definition has been released
•  Abstract class  can be  useful when you  anticipate  creating  multiple versions of your component 
•   An interface  by  contrast is a totally  abstract (this means no implementation for members )   set of  members that can  be thought of defining contract for conduct
•      IS-A vs CAN-DO relationship:  to use an abstract class as a base class the derived class should satisfy the IS-A relationship. Interface imply a CAN-DO relationship. 

Understanding virtual, override and new keyword in C#:

·         The virtual keyword is used to modify a method, property, indexer, or event declared in the base class and allow it to be overridden in the derived class.

·         The override keyword is used to extend or modify a virtual/abstract method, property, indexer, or event of base class into derived class.

·         The new keyword is used to hide a method, property, indexer, or event of base class into derived class.

Abstract functions vs Virtual functions

·         Abstract Function:

1.       It can be declared only inside abstract class.

2.       It contains only method definition not the implementation.

3.       It must be overridden.

·         Virtual Function:

4.    It can be declared inside abstract as well as non-abstract class.

5.    It contains method implementation.

6.    It may be overridden.

 Static

• ·         Static  variable  are special area inside Heap called  High Frequency Heap
• So using static keyword will make your code a bit faster since no object creation is involved. 
• Static class are sealed by default this references can never be garbage collected (unless you null the field). 
•  Static variables are not thread safe.

  Generic Types

Generic types offers more advantages over the normal System.Collections such as Array List.
 Some of advantages are:

• Performance:   Generic types are strongly typed which means no needs for boxing and unboxing (Array List vs List<T>).
• Binary Code Reuse:   algorithms are   written without duplicating type specific code. 
• Compile-time type checking: the correct data type it is enforced at compile time

Reflection

• From MSDN 

Reflection provides objects (of type Type) that describe assemblies, modules and types. You can use reflection to dynamically create an instance of a type, bind the type to an existing object, or get the type from an existing object and invoke its methods or access its fields and properties

References

 http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx