We have a legacy site that was written a while back using MVC. It's a valid MVC for the most part except for the Data Access Layer. The site has Models, Views, and Controllers. However, instead of using Entity Framework, they use web services that use ADO to execute stored procedures.

For example: say we have a page to display all users. We'd have a users.cshtml view, a UsersController.cs class, and a UserViewModel.cs class.

The GetUsers() method in the Users controller would call a web service method called WebService.GetUsers(). This web service would then call a stored procedure named dbo.GetUsers which would contain something like select * from Users where Active = true.

I've never seen this type of approach before and was wondering if it was something that was made up by whoever made this site, or if it's an architecture style from the past?

I would also like to know if this is a good architecture to use.

  • I see that you got an answer from another new contributor, which is fine, I suppose, but may I point out that there is no right answer to the question "is this valid?" It's valid for some definition of valid; what's your definition? – Robert Harvey Nov 13 at 16:09
  • Perhaps I should've gone with "Is this a good or desirable approach?".Yes, there are many ways to do things in MVC. We could potentially put all our business logic in the view but and it might work but that's obviously not a good approach. The approach in my question has pros and cons and I wanted to get feedback on what these would be. – Bruno Nov 13 at 16:31
  • "Good" and "desirable" have the same problems; it depends on what your definition of "good" and "desirable" is. "Pros and cons" has its own problems. – Robert Harvey Nov 13 at 16:36
up vote 3 down vote accepted

Sure, this is perfectly valid. It all depends on the specific use case.

If there are multiple applications which utilize the web service then it makes sense to split that data access layer out into something that multiple applications can reach as opposed to implementing it directly in the MVC site. As far as the difference between using EF and stored procedures go, this is all preference. Their staff very well may have had more expertise in SQL/stored procedures than entity framework in which case it may make sense to use stored procedures.

Personally, I prefer entity framework as well but architecturally, it makes little difference what specific tool you use to query your SQL db. As a side note, it doesn't mean the app is not "valid MVC" just because they aren't using entity framework.

If it is just one app querying the db for data then I would've opted to keep things simple and implement the data layer in the same solution as the current MVC code as I opt to keep things simple when I can. If there's a chance that there will be mobile apps, etc in the future that need to pull data from the db, then I'd implement a web service that pulls data from the db via entity framework but again, the tool you're using to query the db is going to vary pretty greatly from company to company- there are a bunch of ORMs like entity framework and I've seen quite a few companies writing raw parameterized SQL queries in their data access layer.

I hope that helps.

  • that does indeed help, thanks for the insight. What are your thoughts on stuffing all this logic in stored procedures? Personally I think it's a bad idea because it makes it harder to unit test things and because none of the stored procedures are under source control. – Bruno Nov 13 at 15:19
  • I religiously try to keep db as much logic out of db queries as possible. As far as thoughts on how the MVC app portion could be done better, I wouldn't have the controller directly calling the web service but instead create a data access layer in the mvc app that calls out to the web service. You could optionally put in a service layer in between the web layer where your mvc components are and the data access layer that calls out to the web service. That service layer would be where all the business logic goes. – GregH Nov 13 at 15:25
  • So basically, the web service would just return the raw data needed to perform whatever action is desired, it would then pass the data to the service layer which would apply any needed business logic and then give that data back to the web layer which would generally be responsible for http interactions and any needed authorization for the mvc site (role access, etc). Look into onion architecture as that most closely resembles what I'm describing. As with everything else, there are perks and drawbacks. One of the big perks is a large separation of responsibilities. – GregH Nov 13 at 15:27
  • c-sharpcorner.com/article/… – GregH Nov 13 at 15:30

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.