I'm developing an application using Microsoft WPF on top of SQL Server for one piece of a larger system.
This is a college senior project, and I would like things to be as "best practices" as possible for portfolio reasons. I understand that MVVM is the way to go to structure the WPF application itself.
Furthermore, I am interested in taking advantage of LINQ instead of the "SQL query string" method of data manipulation and retrieval, however I am fairly frustrated as I can't seem to get a straight answer on how to do this the right way (or if this is even best practices).
I found a promising tutorial, however it calls on using Linq-to-SQL to create the object relations which I have read as being deprecated, and isn't available in VS2017. I found a dated tutorial that was using ADO.NET for this (~2010) however it was giving me issues.
Should I stick to the "SQL query string" way of doing things?
You can do this using Entity Framework in c#.
Add the Entity Model of your database into your application.
then create an object in the class that you want to invoke data
<your-entities> context = new <your-entities>();
then you can invoke data using linq
var select = from a in context.<table-name>.IEnumerable() select a;
finally you can read data using select variable.
eg-:
foreach(var item in select){
}
Best practices? DON'T use LINQ to SQL. I am not against the idea of something that simplifies things for small student projects, but while it simplifies things, it makes provides a nightmare for DBAs in the real world. Entity Framework can also cause this heartburn, but there are ways around it.
If by "SQL query string" way of doing things as coding SQL query strings and sending to the database from your code. That can work, if things are predictable. But, if you are too dynamic, you just repeat the DBA nightmare.
I would look up repository patterns and learn how to create a repository. While you might not have to do this always in the real world, it is great exercise in learning abstraction. For items where you might need to work on a lot of joins, consider examining the creation of views and build a few stored procedures. All of these will serve you when you leave the classroom for business.
As a bit of trivia, LINQ to SQL was an experiment written on top of reactive extensions (Eric Maier when he was with Microsoft and not bashing Agile). It might not have ever been released had it not been for SQL Server being delayed from a co-launch with Visual Studio 2008. The delay of SQL Server meant the delay of Entity Framework, which meant the "build a site in 15 minutes" talk was FUBARed. Thus, LINQ to SQL became a de facto "standard" and DBAs everywhere started carrying guns to work (okay, the last part is not true, but the rest is).
Related
I am web developer for nine years now.
I love to develop custom CMS and purly hand coded web applications.
I was ok with ADO.NET Data Access model, writting native SQL Queries to the database and calling store procedures via DBCommand.
2 years now i was thinking to move to ADO.NET Entity Framework.
I know there are alot of advantages in terms of productivity but i really don't like/understand the way it work Entity Framework.
In terms of productivity i have create an application that auto generates for me the ADO.NET Code so i don't waste mutch time to code ADO.NET code.
Should i move on Entity Framework?
PS : I am a performance lover.:P
PS 2 :For example, How can i implement a Modified Preorder Tree Traversal to manage hierarchical data (ex : Categories of products) in Entity framework?
PS 3 : I Work with MySql Server
Edit
After a bit of reading, i understand that ADO.NET Entity Framework is wonderful.
It give us alot of benefits that we have to hand craft or "copy-paste" in the past.
Another benefit that comes with it is that is completely Provider independent.
Even if you like the old ADO.NET micanism or you are a dinosaur like me(:P) you can use the entity framework using the EntityClient like SqlClient, MySqlClient and use the power of Entity-Sql witch is provider independent.
Yes you loose some performance.
But with all these cache technologies out there you can overcome this.
As i always say, "The C is fast, the Assembly even more...but we use C#/VB.NET/Java"
Thank you very mutch for the good advices.
It depends.
ORMs work well when you are forced to persist an object graph to a relational storage. The better option would be to use an Object Database. So:
If your application will benefit from using an Object Database and you are forced to use relational storage, then answer is simple: Yes, you need ORM.
If you already have your data layer strategy and you don't need to spend a lot of time using it and you feel it's fine, then the answer is also simple: You don't need ORM., with one simple "but"...
You can't foresee all advantages/disadvantages until you try. And nobody has your mind and your projects. So the better answer would be: Try it and figure it out yourself.
The choice of ORM does not change your data model in most cases. You can use the exact same methods that you used to use, but you now use them in code rather than SQL.
In your MPTT example, you would do the same thing, but it would look something like this in the case of a tree of food items, where the root items left value is 1, and right value 20.
var query = from f in food where lft > 1 and rgt < 20 select f.name;
What's more, if you do discover something you can't do very well in the ORM, you can always just use the ORM to call a sproc that does what you need in SQL.
In fact, even if I wasn't using an ORM to map tables, i'd still use it to call my sprocs because it will automatically create all the wrapper code, parameterize the queries, make it all type safe, and reconstitute it into a data transfer object. It saves writing a lot of boilerplate.
To answer at least one aspect of performance, EF will generate parameterized queries, which is good for performance. Parameterized queries allow the db to store execution plans and the dba to optimize the plans if necessary. Otherwise most queries are treated by the db as totally brand new and thus it creates a new execution plan every time.
Creating My Windows Form Application and using ADO.Net as Data Access layer and
SQL server as my Back End with lots of SP's.
Do i still stick to ADO.NET or go to studying FnH or Linq to SQL? Which shall i choose? Or i still stick in ADO.NET?
Can you give me Recommended WebSites on EF or FluentNhibernate for kick of tutorials..
Thanks in Regards
It's really just up to you to pick one - they're all valid technologies.
If you're already familiar with the low-level ADO.NET constructs, and you don't feel like putting the time into learning a different methodology, you can stick with plain old ADO.NET - this is not going away anytime soon.
If you want to start off with a very simple ORM, I would suggest LINQ to SQL. However, Microsoft has basically left LINQ to SQL in the dust in favor of Entity Framework, so if your project has long-term maintenance concerns, LINQ to SQL may or may not be the best choice. It is a really nice, lightweight, easy-to-use framework though...
If you want to learn the latest MS data access technology, you could try Entity Framework. The initial setup is not too bad, but Entity Framework is a beast, so there might be a bit of a learning curve at some point, if you run into something that works differently than you expect, or you want to learn more. EF is fairly full-featured at this point, but it still lacks some of the functions offered by more mature data access technologies like NHibernate.
Finally, if you want to try something different than the Microsoft offerings, NHibernate is a great framework. You're not going to find the entity designers, property pages, wizards, hand-holding, and stuff like that, but that's almost the point of NHibnerate. In Fluent NHibernate, the primary focus can be on your domain code, and less on the database, which makes it very conducive to unit testing. Entity Framework has gotten better with persistence ignorance, but it still feels a bit heavy-weight compared to NHibernate.
In addition to these, there are several other solid data access technologies that you could look into, but I hope this gives you some info to start with.
I'm getting ready to start a C# web application project and just wanted some opinions regarding pulling data from a database. As far as I can tell, I can either use C# code to access the database from the code behind (i.e. LINQ) of my web app or I can call a stored procedure that will collect all the data and then read it with a few lines of code in my code behind. I'm curious to know which of these two approaches, or any other approach, would be the most efficient, elegant, future proof and easiest to test.
The most future proof way to write your application would be to have an abstraction between you and your database. To do that you would want to use an ORM of some sort. I would recommend using either NHibernate or Entity Framework.
This would give you the advantage of only having to write your queries once instead of multiple times (Example: if you decide to change your database "moving from mssql to mysql or vice versa"). This also gives you the advantage of having all of your data in objects. Which is much easier to work with than raw ado Datatables or DataReaders.
Most developers like to introduce at least one layer between the code behind and the Database.
Additionally there are many data access strategies that people use within that layer. ADO.NET, Entity Framework, Enterprise Library NHibernate, Linq etc.
In all of those you can use SQL Queries or Stored Procedures. I prefer Stored Procedures because they are easy for me to write and deploy. Others prefer to use Parameterized queries.
When you have so many options its usually indicative that there really isn't a clear winner. This means you can probably just pick a direction and go with it and you'll be fine.
But you really shouldn't use non-parameterized queries and you shouldn't do it in the code behind but instead in seperate classes
Using LINQ to SQL to access your data is probably the worst choice right now. Microsoft has said that they will no longer be improving LINQ to SQL in favor of Entity Framework. Also, you can use LINQ with your EF if you should choose to go that route.
I would recommend using an ORM like nHibernate or Entity framework instead of a sproc/ADO approach. Between the two ORMs, I would probably suggest EF for you where you are just getting the hang of this. EF isn't QUITE as powerful as nHibernate but it has a shorter learning curve and is pretty robust.
I am working on a personal project as a way of learning more about C# and .NET, specifically creating an application that utilises a database (MS SQL Server 2008 in my case). Whilst I appreciate there isn't always a definitive "right" way of doing things, given the choice between using an old technology/idea or a new one, I would rather use the new one. For example, one of my aims for this project is to learn, or at least familiarise myself with, WPF rather than using WinForms as I have done in the past.
On that basis, I've been muddling around without a great deal of direction with regards to saving data to my database and retrieving it. So far I've managed to get both those working using TableAdapters but I feel like they are the "old" way of working (my basis for this is that they are listed under Visual Studio 2005 on MSDN). Firstly, am I correct in this assumption? If so, what are the newer methods of saving and retrieving data from a database? I would be grateful of any pros and cons each method offers.
I've Googled and searched MSDN extensively but I don't feel like I am using the correct search terms as I have only succeeded in confusing myself.
I have .NET 3.5, Visual Studio 2008 and Microsoft SQL Server 2008 at my disposal.
Any guidance would be much appreciated.
I would agree that TableAdapters, DataSets, DataTables, etc. are the "old" way of doing things.
The "new" way would be Linq-to-SQL, Entity Framework or NHibernate.
Personally, I like to use a combination of Linq-to-SQL along with plain old DBConnections, DataReaders and DTO's where needed.
If you would like a newer way of doing Database access in .NET, I would recommend looking into LINQ to SQL or the Entity Framework.
There are many many many different ways to retrieve data from SQL Server 2008 using .Net.
Table Adapters are not a bad way; they are core to the .Net Framework, easy to get started with and reasonably powerful, although they do not perform quite as well as other options and often require more memory.
Basically Table adapters are good if your data is structured the way you want to view it. If you want to view data in a different way to it is stored you can do this with a table adapter but you loose the ability to write back changes to the database, this is OK if you are just generating a report.
If you want to view and change the data and the data is not in the structure you want to view it you need entity framework so you can query the data to get it into a different format and still have the ability to write any changes back. This is what the call the data from the server the MV to the display the VM
I am about to start a new project and am deciding what data access technology I will be using... I really like LINQ to SQL for a variety of reasons but should I start the new project using the Entity Framework instead??
I have this perception that the Entity Framework is more bloated and needlessly complicated, thus accounting for part of the reason I was thinking about going with LINQ to SQL... but as I said this may only be perception on my side as I haven't used the Entity Framework all that much.
So which would people recommend I use for starting a new project today (note this app will be around for years to come)?
Cheers
Anthony
EDIT:
We are SQL Server shop so we don't need database vendor independent.
Also is the generally agreed best way to abstract data access atm by using the Repository pattern which works with my domain objects?
LINQ to SQL is about rapid development and simplicity. If your data model is complex, or might become so, you will be better off using a more robust framework.
That said, more important than your data access tool is how well you abstract it from the rest of your code. Done right, you should be able to start with LINQ to SQL and switch when you outgrow it (or when EF 2 4 comes out).
Note that EF 1 is far from complete. It lacks all kinds of features you do find in LINQ to SQL, one of the more important ones being actual foreign key properties (can you imagine these don't exist in EF 1?)
Also, EF 4 will pretty much have all features of LINQ TO SQL, and both will generate relatively comparable (code wise) external API, so unless you're coding to very LINQ to SQL specific API's, it should be relatively easy to migrate to EF4 later on, 'simply' by replacing the LINQ to SQL .dbml with EF4's equivalent.
Linq to SQL works best in an active record / one table per class paradigm. If you need to span your class across several tables, or support complex inheritence then it may not be the best choice. Also, Linq to SQL doesn't natively support many-to-many relationships (there are workarounds).
If neither of those sound like they'd affect you, then Linq 2 SQL may be a good choice. It's a great lightweight data access strategy.
Linq to SQL can be used to implement the repository pattern very well given the above constraints. Google will turn up several viable Linq repository examples.
Have you taken a look at Subsonic - now in version 3 it is basically a linq to sql DAL that makes it possible to have full linq to sql of your entire database in under 5 mins. And it runs off T4 templates, so if you want to add to the templates it is REALLY EASY
http://www.subsonicproject.com/
I wrote up a pretty lengthy blog post on choosing a .NET ORM:
.NET and ORM - Decisions, decisions
Basically, NHibernate is your best bet. If you insist on something with simplicity like LinqToSql, consider SubSonic. I would not recommend either of the Microsoft options: LinqToSql or EntityFramework.
Deciding whether to use the repository pattern or not is situational depending on your requirements.
Check out: http://www.icemanind.com/Layergen.aspx