I am a learner of MVC (4). I have gone through some tutorials on MVC 4. Those are simply awesome. But all of those have used EF with LINQ to SQL for database operation. If i want to use T-SQL for database operation, how can i do it? Should i write sql query in Model or in another library? Where will i place my data access layer?
I googled with this question. But no satisfactory technique found.
I tried to implement my TSQL when I first started doing MVC4 & WPF/WCF. TBH the number of hours I wasted I was probably better off learning the Linq I now know sooner.
I found that if I created a good level of relationships in my database I was able to easily achieve in Linq what I could in TSQL.
Related
I'm new to ASP.NET MVC and writing one of my first applications using Entity Framework. There are some quite complicated SQL queries and I'm finding it much easier to just write a stored procedure rather than try to do it in Linq.
Is it an acceptable practice in the industry to mix Linq and stored procedures?
Yes, its perfectly acceptable.
Entity Framework is very powerful and has its place. But there are times where the control and readability/maintainability a stored procedure gives you, can provide a better solution.
I would suggest your goal is to use the right tool for the job.
Maybe describing the problem you are trying to solve and what you have attempted and we can suggest alternate ways.
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 !
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.
So I have a layered ASP.NET MVC proof-of-concept application with good separation between presentation concerns, business logic, and infrastructure concerns. Right now it is operating off of a fake repository (i.e. LINQ queries against static IQueryable objects). I would like to create a functional SQL repository now.
That said, I don't want to simply tie it into a database that has a 1-1 mapping between tables and entities. That wouldn't meet the business need I am hoping to solve (partial integration with existing database - no hope for convention over configuration).
Do you have suggestions for which ORM / mapping tools I should consider and/or avoid?
Do you have suggestions for articles/books I could look at to help me approach this topic?
Would it be better to simply use parameterized queries in this scenario?
Entity Framework in version 4 would definitely allow you to:
have a mapping between the physical database schema and your conceptual schema, e.g. having an entity mapped to several tables, or several tables joined together forming a single business entity
grab data from views (instead of tables directly)
use stored procedures (where needed and appropriate) for INSERT, UPDATE, DELETE on every entity
NHibernate sounds like a good fit for what you are looking for. You will be able to make your repositories call queries in either HQL or using the API, either way you can get to your database and shape the data to fit the way your repository is being used. It will always be hard to make a square peg fit into a round hole though. SO has lots of nice support when you get into using NHibernate, good luck.
As you mentioned in the question, it is very debatable to choose an ORM. Different people will have different project needs. I am not exactly sure what will take priority for you. Here is what I have tried myself.
NHibernate seems to be the most commonly used ORM in DotNet projects. I feel it suffers from a typical open source problem. It offers so many features but the documentation really sucks. If you have lots of time at your disposal you can give it a shot.
Another options is to go for something like Entity Framework. Its very easy to set up and get up and running. With version 4.0 and the CTP there is provison for code first as well as fluent mapping and configuration. Since you have said you would want to keep the domain model separated EF 4 will help you because it has a notion of conceptual model which is an abstraction over the mapping layer.
You can refer to few links below for the blogs I had written based on my experience
http://nileshgule.blogspot.com/2010/08/entity-framework-hello-world.html
http://nileshgule.blogspot.com/2010/09/nhibernate-code-first-approach-with.html
http://nileshgule.blogspot.com/2010/09/entity-framework-first-query-using.html
http://nileshgule.blogspot.com/2010/09/entity-framework-learning-series.html
I just started with ASP.NET MVC 1.0. I've read through some tutorials but I don't have any good ideas on how to build my model.
I've been experimenting with LINQ to SQL. Can't say I like it that much, but I'll give it a try. I prefer using SQL Stored Procedures, but it doesn't seem to work very good together with the optional parameters in my stored procedures.
The project is a prototype, but I would like to start with a good design right away.
The database will probably contain around 50 tables and stored procedures will be used for all queries and updates. Some procedures will also return multiple results. How would the best way to design this model?
All and any ideas are welcome. Should I even use LINQ to SQL? Should I design my stored procedures to only return one result? I feel a little bit lost.
You can use stored procedures with LINQ. You simply need to replace the autogenerated statements on your entities with your stored procs. Look at the properties for the entity (table) in the designer to change these. Your stored procedures won't be able to return multiple results as they need to map onto a collection of either one of your entities or an autogenerated entity, i.e, onto a collection of a single class.
Having said all that, I'd give it a go without using stored procedures. The LINQ code is fully parameterized so you already have this benefit. You'll find that LINQ allows you to easily build up queries alleviating your need for the optional parameters in your stored procs and, likely, resulting in more efficient queries as you don't need to build extra logic into your query to handle the optional parameters. Once you start using LINQ I think you'll find that the power and expressiveness in the code will make you forget about using your stored procedures.
You may still have a need for stored procs or table-valued functions for complex queries -- that's ok. If they map onto an existing entity, you can simply drag the proc/function onto the entity in the designer and you get a nice method on your data context that runs your SQL and returns collections of that entity. If not, I often create a view for the proc/function schema, use that as an entity, and attach the proc/function to it.
May I ask why you need to use stored procedures for this project? They have almost no value today if you are working with a modern database. Parameterized SQL using a good ORM will give you the same cached execution plans and security benefits that you are looking for with stored procedures.
I would recommend NHibernate because it's a far better way to achieve persistence ignorance. And IMHO this is the goal of anyone designing a model. You should be thinking object first instead of data first.
The best resource around is a screencast series by Steve Bohlen "The summer of nhibernate"
Also LINQ to NHibernate is available and works great for any dynamic query that you might need to write.
The only pain you will notice with NHibernate is the XML, but if you really enjoy the ORM you could write a fluent interface instead using FNH.
I found NHibernate to be the best tool around for modeling a domain because your objects are 100% infrastructure free and this allows you to do anything you want with them without having to worry about the database. Also if you are into unit testing of any kind this will make your life much easier :P
Edit
Part of the reason I replied to your question is that I have built many a system using stored procedures and found to regret that decision later. But in my situation I had a requirement by a dba so I couldn't step away from the norm.
If you are already looking at LINQ to SQL I would simply encourage you to look at NHibernate as another great option to achieve the goal of persistence ignorance.
When I got away from thinking about the problem data first it allowed me to work at a much higher level and take advantage of the .net platform for solving problems. TSQL has its place but if you are writing an application and want to maintain it - try to think about how your domain objects will work together in memory first.
When linq to entities was released, everybody say that linq to sql is dead.
But most books and sample projects by microsoft employees, use mvc+linq to sql.
There is some reason for that? The linq to sql seems better for POCO, would it?
Linq to SQL had its origins in a thought experiment. Linq needed a proof of concept, and Linq to SQL provided that.
Since then, many in the user community (including a few prominent Microsoft employees) have embraced Linq to SQL as the lightweight SQL Server ORM of choice, especially for small projects like NerdDinner.
The furor began with this post by the ADO.NET team. In it, they said that Linq to SQL will be maintained, and features added based on user community feedback, but that the Entity Framework would be the primary focus of future data access efforts.
Many in the user community interpreted this move as "Microsoft is killing Linq to SQL."
Microsoft didn't help matters when it disabled the provider model for Linq to SQL by sealing some critical classes, effectively making Linq to SQL usable only with SQL Server. The Entity Framework will be the ORM of choice for multiple data providers.
Unfortunately, the Entity Framework seems not quite ready for prime time.
So it depends on who you believe. Do you believe the speculations (and they are just speculations) of many bloggers who say that Linq to SQL is truly dead and buried, or do you believe people like Damien Guard of Microsoft, who says that Linq to SQL has a long life ahead of it?
Linq-to-SQL is a great technology and very easy to use, so it's extremely well geared towards demos, and it's a perfect choice for smaller, more straightforward projects, too, where you have more or less a straight 1:1 mapping from your tables in SQL Server to your objects in memory.
And those are the most restrictive limitations of Linq-to-SQL:
SQL Server only
straight 1:1 mapping from tables to objects in memory
If that's okay with you, go ahead and use Linq-to-SQL ! By all means - MS is still adding features and fixing it for .NET 4.0 - it's not dead by a long shot.
Entity Framework in its v1 version available right now has some warts, as other posters have rightfully mentioned (no POCO support, no "domain design first" approach and many others). But the EF v4 feature set looks very compelling, and will give Linq-to-SQL a run for its money!
The main advantages for EF vs. Linq-to-SQL in an enterprise environment are its database independence (you can hook it up to Oracle, Firebird, DB2, many others) which can be crucial, and it's ability to present you with an object model that looks quite different from the physical storage model in the database (by virtue of the mapping between the conceptual layer and the physical storage layer).
So it's really a matter of what is it you need: do you need a quick way to get started (demos, simpler apps) - then your choice clearly is Linq-to-SQL (at least for now), or do you need a flexible mapping approach against a non-SQL Server backend - then your choice will be Entity Framework.
Marc
The only reason the samples were written with LINQ-to-SQL is because setting it up is fast and simple.
Otherwise you can use any ORM to suit you, whether it be EF or NHibernate or whatever.
Personally, I'd start getting used to the Entity Framework now. Since it has more features, is provider-independent, and being developed (perhaps) more aggressively. The two most common complaints I hear are lack of POCO and lack of Lazy Loading. It would appear that both of these are addressed in .NET 4.0 http://blogs.msdn.com/adonet/archive/2009/05/28/poco-in-the-entity-framework-part-2-complex-types-deferred-loading-and-explicit-loading.aspx
Besides being potentially faster (to get started with) or simpler, I'm not sure of any particular advantage to use LINQ to SQL, in the long run. Is anyone aware of any?
The nerddinner sample chapter written by ScottGu uses Linq-To-SQL, he does not endorse LINQ-to-SQL but does not promote LINQ-To-Entities either. With ViewModel (Stephen Walther has a nice post on this) & the repository pattern, LINQ-To-SQL is perfect for developing ASP.NET MVC applications
In my opinion, Linq to Entity is not a good candidate at the moment. One of the things that I've come to dislike about Linq To Entity is the lack of lazy loading, which drove me up the wall every time i wrote my repositories. I think, that's what killed it for me. The other thing is the whole issue with attaching and detaching entities which are being used by multiple instances of the object context. That was another killer for me, which resulted in a lot of hacking trying to recreate entity relationships and etc. Frankly, I think a better thing to do would be to wait for the next release of this framework. I think good things are coming for it :)