1

Warning : Noob Question !

I am being pushed into using MVC & EF for my projects; both of which are new to me. The MVC part I'm not too stressed about, but EF bothers me, there are some key concepts that my head just isn't around yet.

My database is a repository of millions of records which users will need to perform very complex searches upon.

Seems that the majority of articles I read are hooking the DB up to the Application with EF, and filtering data client-side. That's just a 'No' for me, and I can't imagine that I am the only one.

Then I have seen some articles that talk of pushing the filters back to the DB using LINQ/IQueryables. That sounds more reasonable, at least I would not be bringing back more data than I need. But my more complex queries would be nightmare to build in LINQ (I imagine).

Still, what bothers me, is that I have SQL Server to do all that heavy lifting for me. Store Procedures that can utilize most powerful mechanisms for the most complex queries imaginable. Isn't that what SQL Server was born to do ?

I am still thinking to bulldoze ahead with my old Skool brain.

  • Build Models that reflect my data tables/stucture.
  • Populate my Models 'manually' via Stored Procedures

Can anyone point out where I might be viewing all this wrongly ? I know that there is heaps of info on Google, but most just jump into how to technically do 'A'... with little discussion over 'why' we are doing 'A' or what the alternatives are.

Thanks for any comment !

SimonB
  • 962
  • 1
  • 14
  • 36
  • It's hard to find robust examples of brownfield apps with complex DBs that are sometimes ill-suited to EF, and as you say, sometimes this can result it totally ludicrous, cumbersome queries being generated. You can, however, use stored procedures to execute your queries that return your desired model structures. See this related question for an example: http://stackoverflow.com/questions/20970416/using-stored-procedure-in-entity-framework – stephen.vakil Aug 31 '16 at 18:32
  • I don't know anybody that would bring millions of records client side. Lot's of tools for paging out there. Yeah, if you have something overly complex you can use a SP, but LINQ is pretty powerful. It's an uncomfortable paradigm shift for many to think in terms of objects versus relational data. – Steve Greene Aug 31 '16 at 18:36

1 Answers1

0

Point 1 :

Yes,you can start it as you mentioned.That is Build Models that reflect my data tables/structure.That means you're going to create everything by hand manually. Which is very tricky task hence you're already having the db.So I would like to suggest to use EntityFramework Reverse POCO Generator for generating the required models from your db.

Point 2 :

Yes,You can use Stored procedures with the EF code first.But be careful not to use EF core at this moment. B'cos the SP support is at the beginning level right now.So you can start with EF 6.X and later with the maturity of the EF core where you can move easily to the EF core world.

Point 3 :

You don't need to worry about the size of the records which you have to show on the UI. B'cos there having so many sophisticated UI components which are build for showing massive data on the UI. You can choose either from free or paid once.

Sampath
  • 63,341
  • 64
  • 307
  • 441
  • Thanks Sampath (Stephen & Steve also) – SimonB Aug 31 '16 at 20:31
  • 1
    Thanks Sampath (Stephen & Steve also). For me, the main thing here is that no one is screaming at me for asking something stupid - knowing my head isn't too far detached from reason is always a good start. "create everything by hand manually" was a bit of a concern. I was wondering if I could create my model from DB, but then 'detatch' it from the DB so it was just stand alone. My head tells me that I should be able to do that, but the POCO Generator link link kind of points that I should look at that instead. Again, thanks. – SimonB Aug 31 '16 at 21:19