ASP.NET MVC without Models and Entity Framework [closed]

Answer 1

It is fine not to use Entity Framework, using ADO.NET can be acceptable. Yes it's possible.

If careful you can make your data access code more efficient than the code EF will generate. Maintenance might well be less efficient though, because EF does a lot of work for you. Bear in mind that the cost of maintenance is very expensive.

However, I don't understand why you want to avoid models and yet use MVC. I would not recommend that approach.

Answer 2

My question here is that is it possible?

Of course that it is possible. With one little exception: MVC without Models is not MVC :-) It's VC, which personally I never heard of. Neither as a design pattern nor as a framework. Sounds more like (WC :-))

What is the performance difference between both ways?

You can't get anything faster than the raw ADO.NET. So, yeah, that will be faster compared to using an ORM.

Of course you will have to write far more code as you will still have models to map the results from your queries. Don't think that the fact that you are not using EF relieves you from the responsibility of using Models. Also don't think that you will be using DataTables.

So basically you will have your Data Layer work with those models. The only difference will be the implementation.

Let's take an example.

Define a Model that will represent your business entity that you intend to be working with in your application:

public class Person
{
    public int Id { get; set; }
    public string Name { get; set; }
    public int Age { get; set; }
    public DateTime Dob { get; set; }
}

then define your data access contract (a.k.a the operations you are willing to perform with your model):

public interface IPeopleRepository
{
    IEnumerable<Person> Get();

    ... other operations you want to perform with this model
}

then you could have your implementation:

public class ADOPeopleRepository: IPeopleRepository
{
    public IEnumerable<Person> Get()
    {
        string connectionString = ...;
        using (var conn = new SqlConnection(connectionString))
        using (var cmd = conn.CreateCommand())
        {
            conn.Open();
            cmd.CommandText = "SELECT id, name, age, dob FROM people";
            using (var reader = cmd.ExecuteReader())
            {
                while (reader.Read())
                {
                    yield return new Person
                    {
                        Id = reader.GetInt32(reader.GetOrdinal("id")),
                        Name = reader.GetString(reader.GetOrdinal("name")),
                        Age = reader.GetInt32(reader.GetOrdinal("age")),
                        Dob = reader.GetDateTime(reader.GetOrdinal("dob")),
                    };
                }
            }
        }
    }

    ... implementation of the other operations you want to perform with this model
}

and then as usual you might have a controller to work with this repository:

public class PeopleController: Controller
{
    private readonly IPeopleRepository repository;
    public PeopleController(IPeopleRepository repository)
    {
        this.repository = repository;
    }

    public ActionResult Index()
    {
        var people = this.repository.Get().ToList();

        // Depending on the requirements of your view you might have
        // other method calls here and collect a couple of your domain models
        // that will get mapped and aggregated into a single view model
        // that will be passed to your view

        return View(people);
    }

    ...
}

All that's left now is to register the ADOPeopleRepository concrete implementation of your Data Access Layer into your favorite container.

See how things get layered. Now, if you wrote your current ASP.NET application properly, you probably already have the Models, the interface and the repository implementations. So migrating it to ASP.NET MVC will be a piece of cake where all you need to do is write a couple of view models and views.