What are the core interfaces of Hibernate framework?

1. Session Interface: The basic interface for all hibernate applications. The instances are light
weighted and can be created and destroyed without expensive process.
2. SessionFactory interface: The delivery of session objects to hibernate applications is done by
this interface. For the whole application, there will be generally one SessionFactory and can be
shared by all the application threads.
3. Configuration Interface: Hibernate bootstrap action is configured by this interface. The location
specification is specified by specific mapping documents, is done by the instance of this interface.
4. Transaction Interface: This is an optional interface. This interface is used to abstract the code
from a transaction that is implemented such as a JDBC / JTA transaction.
5. Query and Criteria interface: The queries from the user are allowed by this interface apart from
controlling the flow of the query execution.
What is the use of session in hibernate?
A Session is used to get a physical connection with a database. The Session object is lightweight and
designed to be instantiated each time an interaction is needed with the database. Persistent objects
are saved and retrieved through a Session object.
What is detached queries?
The DetachedCriteria class allows you to create a query outside the scope of a session and then
execute it using an arbitrary Session.
Different approaches to represent an inheritance hierarchy

Table per Hierarchy (TPH): This approach suggests one table for entire class inheritance
hierarchy. Table includes discriminator column which distinguish between inheritance classes.
This is a default inheritance mapping strategy in Entity Framework.

Table per Type (TPT): This approach suggests seperate table for each domain class.

Table per Type is about representing inheritance relationships as relational foreign key associations.
Every class/subclass that declares persistent propertiesincluding abstract classeshas its own
table. The table for subclasses contains columns only for each noninherited property (each property
declared by the subclass itself) along with a primary key that is also a foreign key of the base class
table.

Table per Concrete class (TPC): This approach suggests one table for one concrete class,
but not for the abstract class. So if you inherit the abstract class in multiple concrete classes
then the properties of the abstract class will be part of each table of concrete class.

Table per Concrete type is somehow the simplest approach suggested, yet using TPC with EF is one
of those concepts that has not been covered very well so far and I've seen in some resources that it
was even discouraged. The reason for that is just because Entity Data Model Designer in VS2010
doesn't support TPC (even though the EF runtime does). That basically means if you are following
EF's Database-First or Model-First approaches then configuring TPC requires manually writing XML
in the EDMX file which is not considered to be a fun practice. Well, no more. You'll see that with Code

First, creating TPC is perfectly possible with fluent API just like other strategies and you don't need to
avoid TPC due to the lack of designer support as you would probably do in other EF approaches.