CODEWITHSUNDEEP
asp.net-mvcinstantiation
Vishal
Vishal

Reputation: 12369

Should I create a new object everytime or create a single object?

I am using asp.net mvc and entity framework.We have the data access layer and business layer. Now since the data access does all the querying I need to create a dataccess object in the business layer classes. Now I am not sure whether I should only create a single object or have it instantiated locally every time. Here is an example -

First Way - 

class Employee_Business
{
    public Employees GetEmployee()
    {
        DataAccess dao= new DataAccess();
        return dao.GetEmployees();
    }

    public Employee GetEmployee(int id)
    {
        DataAccess dao= new DataAccess();
        return dao.GetEmployee(id);
    }
}

Second Way - 

class Employee_Business
{
    DataAccess dao;
    public Employee_Business()
    {
        dao = new DataAccess()
    }

    public Employees GetEmployee()
    {
        return dao.GetEmployees();
    }

    public Employee GetEmployee(int id)
    {
        return dao.GetEmployee(id);
    }
}

Also another option is I could make some of the methods static in the DataAccess layer. In that case there would be no instantiation. But I am not aware of the problems that it may cause. Also I have heard about the Singleton Pattern but dont know if that's really the need in such a simple scenario. I just want to know the best practices in this case. I am sure everyone has done this please enlighten me thanks !

Upvotes: 0

Views: 363

Answers (4)

Arjan Einbu
Arjan Einbu

Reputation: 13672

From the two listings you provide, you should use the second one. You don't need a new connection (or context) for each query (if you query more than once in a request), but you should create a new instance of the Employee_Business class for each request. (So; no singletons for the connection...)

Upvotes: 1

Guffa
Guffa

Reputation: 700382

Each request needs it's own connection to the database, as a web application is multi threaded. Several requests can be running in separate threads at the same time, and each thread needs it's own connection to the database.

(Well, the threads could actually share a single connection, but that would be very limiting, and it's just more complicated to code.)

Creating a new object instance for each request is simply the easiest solution. It's possible to use a singleton class or static methods, but then you have to manage the connections so that each request still uses it's own connection.

Upvotes: 1

Matthew Abbott
Matthew Abbott

Reputation: 61599

You need to consider how web applications work. Your application will be servicing multiple requests, quite likely simultaneously, and if so you need to consider how your class is going to be used:

  1. If the class is performing read-only operations, you can probably use it as a static instance without worrying about thread management.
  2. If the class is performing write operations that can change its internal state, then you need to ensure that if it is static, that it has mutexs/monitors/locks where appropriate to ensure that atomic operations are satisfied.
  3. If the class is performing write operations that don't change its internal state, you can probably use it as a static instance without worrying about thread management.

When you design your types, its useful to consider these scenarios.

Upvotes: 1

Justin Niessner
Justin Niessner

Reputation: 245429

If I were you, I would do some serious reading up on the Unit of Work pattern. That should take care of your question fairly thoroughly:

Patterns of Enterprise Application Architecture: Unit of Work

What it really boils down to is that each set of operations that you perform through your Data Access Layer should really be part of a single Unit of Work. That Unit of Work ties all of the operations together and makes sure everything happens in sync.

There are plenty of examples of the Unit of Work pattern in .NET using Entity Framework that you should be able to adapt to suit your needs.

Upvotes: 1

Related Questions