I am getting into more detail with my advances in MVC and started out using
the entity framework to build repositories and contexts for intefacing with
data in my SQL Server database.

Previous to this I coded my own SQL using the SQL command namespacess and
some data adapters instantiating objects to implement them in data class
library methods.

I am also using LINQ now and have been able to handle everything using it.
The other day I starting getting into data requests that I would normally
have used subselects with lists or more complex joins with other tables.

I was wondering if those that have been using MVC find it normal to mix the
built in entity framework database interfaces with their own SQL in SQL commands
or stored procdures as they see fit or should one approach be used only?

I was wondering if those that have been using MVC find it normal to mix the
built in entity framework database interfaces with their own SQL in SQL commands
or stored procdures as they see fit or should one approach be used only?

Most coding guidelines would point to the use of a single approach. However, as your application grows and performance may become an issue, you may need to find a middle ground.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.