I am working on architecture of mid sized web application & for my DAL layer i am having 3 options
1) Traditional Stored proc Based Architecture (Using NTiers Template of Codesmith)
2) LINQ To SQL (or PLINQO Template of codesmith)
3) LINQ To Entity
From above LINQ to Entity is out of reach as we need to start application very quickly and we don't have the sufficient skillset for the same and as team has never worked on any OR/M tools it will be steep learning curve for them (This is what i read some where)
I prefer to go ahead with LINQ to SQL (But only fear is microsoft is not going to support or enhance LINQ to SQL further), from my point of view if microsoft is not going to enhance it further i am not having any issue as whatever feature i require in my project it is sufficient.
Now my issue is should i use linq to sql or should i stick to traditional architecture ?
OR else any other option is there ...
EDIT : I am going to use SQL Server as database and it does not require to interact with any other database
One of the most important objective in designing DAL Layer is faster development and maintainability for future database table changes, as there are chances that field may increase or decrease in future.
Also if you feel that any ORM tool is really good and does not have steep learning curve then also we can use
Please provide suggestions
As you are working in medium size project, I would suggest you to use LINQ-TO-SQL because of these advantages
Advantages using LINQ to SQL:
•No magic strings, like you have in SQL queries
•Intellisense
•Compile check when database changes
•Faster development
•Unit of work pattern (context)
•Auto-generated domain objects that are usable small projects
•Lazy loading.
•Learning to write linq queries/lambdas is a must learn for .NET developers.
Regarding performance:
•Most likely the performance is not going to be a problem in most solutions. To pre-optimize is an anti-pattern. If you later see that some areas of the application are to slow, you can analyze these parts, and in some cases even swap some linq queries with stored procedures or ADO.NET.
•In many cases the lazy loading feature can speed up performance, or at least simplify the code a lot.
Regarding debuging:
•In my opinion debuging Linq2Sql is much easier than both stored procedures and ADO.NET. I recommend that you take a look at Linq2Sql Debug Visualizer, which enables you to see the query, and even trigger an execute to see the result when debugging.
•You can also configure the context to write all sql queries to the console window, more information here
Regarding another layer:
•Linq2Sql can be seen as another layer, but it is a purely data access layer. Stored procedures is also another layer of code, and I have seen many cases where part of the business logic has been implemented into stored procedures. This is much worse in my opinion because you are then splitting the business layer into two places, and it will be harder for developers to get a clear view of the business domain.
There is no absolutely preffered way of writing DAL. These are all options. Which one to choose depends on your project, your skills and your inclinations.
Normally, with LINQ you can expect to be more productive. On the other hand, the DAL built with stored procedures can be expected to perform faster.
The issue only comes when you need some specific queries that the default LINQ to SQL provider won't be able to generate to be blazingly fast. In that case you will have to tap into your LINQ code to plug in your custom stored procedures where needed.
Regarding LINQ to SQL support and further development, it was grounded a long time ago already. So no official further development. Note: that is true for LINQ to SQL (it will be taken over by EF) relational solution, not for the main LINQ functionality.
Entity Framework in its v.1 only received massive critics. You're advised to wait until v2 comes out.
The most important limitation with LINQ (over Entity Framework or any other popular ORM) is that it doesn't support 1 to n mappings. That is, each your LINQ class can only map to a single table, not represent some sort of view over several others. Maybe it's not important to you, but maybe it is. Depends on your project.
The argument of stored procedures vs ORM's is long-standing and unlikely to be resolved any time soon. My recommendation would be to go with an ORM (Linq-to-Sql in your case).
Yes, stored procedures will always be faster since the queries are precompiled. The real question you have to ask yourself is whether you have such a performance-intensive system that your users will actually notice the difference. Keep in mind that using stored procedures means that you will need to manually write all your own queries where using an ORM does this for you. This usually means that an ORM will speed up your development.
Since you mention that speeding up development time is one of your goals I would recommend Linq-to-Sql - otherwise you will basically write the entire DAL yourself.
All of the options you've provided have significant drawbacks. None of them meet the requirements you've set out.
You need to prioritize what is most important for you.
If learning curve is your biggest issue, stay away from all ORMs if you are already comfortable with ADO.NET, DataTables, etc.
If development speed is your biggest issue, you should learn an ORM and go that route. The easiest ORM to recommend is NHibernate. Every other ORM has significant weaknesses. NHibernate works in the vast majority of projects, whereas other ORMs are much more situationally appropriate (depending on your DB design, model design, agility requirements, legacy schema support, etc.). All ORMs have learning curves, they just come into play at different times and in different ways.
Just to expand on #Developer Art, using the traditional stored proc approach enables you to put business logic in the database. Usually you will want to avoid this, but sometimes it is necessary to do. Not to mention you could also enforce constraints and permissions at the database level using this approach. It all depends on your requirements.
With the limitations mention I would say just stick to adhoc/custom queries and ADO.NET and not go for any jazzy stuff. Also stored procedure based DAL are faster is a notion based lame arguments like stored procedures are precompiled but they are not. All that they have is query plan cache. So lesser the investment in stored procedures the better you are. My advice ADO.Net and custom dynamic queries constructed from entity objects.
Related
I need a help on the database access in 3-tier architecture. I am developing application in asp.net and linq. In database there are at least 9 master tables and total of 22 tables. For managing data I need to use a view for each master table.
My question is what is more convenient on runtime or for faster execution?
To use page level queries (using multiple joins having at least 5-6 tables) in DataAccessLayer using linq
To use view and refer them in DataAccessLayer
Adding all queries to a stored procedure and then bind them all.
Which one is best practice? Is views makes page heavy while runtime?
Linq2SQL queries generally wind up as parameterized queries on your database.
There are many discussions on SO comparing the difference in performance like Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS's? and Stored Procedures vs Parameterized Queries
I believe the concensus is that the benefit of the flexibility that an ORM like Linq2SQL gives generally outweighs any perceived performance loss.
IMO, LINQ2SQL will do 90% of the job just fine for most of your data access requirements, and if you have any special needs where a PROC makes more sense (e.g. a really data intensive or batch transaction), you can write one or two procs and these to your DataContext.
However, while we are at it, I wouldn't consider Linq2SQL on a new project. Why not look at Entity Framework 4+? (OP is using .NET 3.5)
Edit
If your table Foreign keys are set up correctly, when you drag your underlying tables into your Linq DBML's, you will find that you hardly ever need to join 'manually' as the ORM will handle the underlying navigation for you.
e.g.
var myUpvotes = Users.Where(u => v.UserId == someUser)
.Votes.Where(v => v.Upvote == true)
.Count();
One concept you will need is Eager vs Lazy loading. This will definitely impact the performance of your 'joins'
I think best practice would be your #1, but you must keep an open-mind about bringing #2 or #3 to bear on the problem if the performance needs demand it. In other words, run with #1 as far as you can, but be willing to use #2 or #3 to improve those parts of the code only if/when you need it.
I've found (and agree with #nonnb) that the productivity improvement and flexibility of using Linq2SQL / ORMs makes it the right choice most of the time, but there are a few times when you need to be willing to make use of a strategic SP in your overall plan - its not an either/or decision; use both as necessary. Generally SP's will be faster, but most of the time not enough to make a difference in your application - but they should be kept in your toolset because in the right scenarios, they can make HUGE improvements when they are really needed.
Let's say we are developing an E-Commerce Web application for a small to medium sized business. Let's further assume that the business is likely to scale over time. In other words, the product line will typically grow.
Up to now I have developed n-tier solutions using ADO.NET and stored procedures with the help of the SqlHelper class. For bigger applications I have used Enterprise Library (2.0).
I would like to move towards an ORM-based approach and am starting to learn LINQ as well as making the switch from ASP.NET Web Forms to ASP.NET MVC. I do not want to go with LINQ-to-SQL. The question is not whether an ORM is required but if the Entity Framework ORM is overkill for such a project. I don't mind a learning curve if it is warranted for the task in hand.
As regards "overkill", I would like to know if:
EF is faster than someone with the correct skills coding queries manually
EF leads to unnecessary code bloat
EF unnecessarily shields devs from code-level details of their queries
LINQ-to-Entities is suited for projects of this size
In fact, if anyone thinks that an ORM is overkill for such project I'd like to hear reasons why.
EF is not overkill for web apps.
I disagree with a lot of what is stated in your referenced article. I do agree devs should have decent skills with SQL BUT ORMS do a great job in getting a devs job done more quickly.
Speed of ORMS - They are getting
better all the time & they allow you
to call SP's or modify the queries to
get max speed when necessary. There are also great profilers out there for monitoring ORM performance like EFProf.
Slows down the coding process -
Really!!! Once learned it speeds it
up.
Devs needing to know SQL - I agree.
However, ORMS especially with LINQ
syntax often allow devs to write more
complex SQL than they would have on
their own.
Devs write efficient queries already - REALLLYYYY!!!! Just ask the DBA his/her thoughts! I happen to think I do but so does everyone else. See the problem. :-)
Code Bloat - Have to disagree, especially with ones that have LINQ.... It often makes the code more readable and reduces the line count often.
Forget about LINQ - This ship has
sailed. LINQ Rocks!!!! Go with it or
be left behind. It's not just used in ORMS. It can be used against, arrays, objects, XML, files, twitter and the list goes on and on.... Get to know LINQ.
The article talks about some of the inspiration of the latest developments out of MS as coming from Ruby on Rails. ROR has an ORM based on Active Record in it.....
ORMS are good. They don't have to be used everywhere and everytime but they are good and should be considered.
Although this is a general answer be wary of any opinion which has these comments in:
"X tool stinks, I write in Y tool and I can do it faster than in X tool."
Or course a Latin speaker speaks better in Latin.
EF has a learning curve, but anything new does. EF is not overkill, but as per any system being written use the right technology for the right project.
Looking at the article, the first thing I would see and disagree with is this:
I strongly believe that modern web
developers should:
•Love databases.
•Write highly efficient queries.
•Minimize code.
•Design self-evident user interfaces.
•Work quickly.
I am not sure how many people view web development, but in my mind a web devloper should focus on functionality and business rules. The pure database and SQL code should never be done by someone on my team that would be more productive writing business functional code.
This is where Entity Framework comes into play. It is considered a Rapid Application Development tool (as are most other ORMs). These tools are built specifically to allow you to focus more on how to fulfill the user requirements and less on what the right way to write a query is.
With that being said, I would also say that using the tool naively could be dangerous. When you use Entity Framework you still have to be cognizant of the implications of using the object graph that you are requesting.
It is by far not overkill, the tool is very simple to use and simple to learn. I would argue that it is easier to "fix" an Entity Framework rather than fixing a raw SQL Query and ADO transaction set.
On smaller projects my base recommendation is almost always go with some type of ORM. On enterprise applications you have to be a bit more careful and it entirely depends on budget :-).
An ORM can be quite useful, if used properly and you understand what it's doing for you. You should definitely use one, if you already have some understanding of database design and querying.
The point of the article, primarily, is that the concept of not having to learn anything about database design and querying somehow makes your life better is a fallacy. I prefer very thin layers of abstraction between code and database - I feel that lets me focus more on good user experience.
I personally feel the press behind EF is encouraging new coders to ignore some necessary basics. I've worked with some of them, and think they were done a disservice.
Of course, there are those that will very strongly disagree. No problem!
I know developers who started off loving it, and now don't. But I also know developers that love EF and swear by it.
I've used EF, LINQ to SQL and NHibernate and others over the years.
Best advice: give it a try. Come to your own conclusion.
(Disclosure: I'm the writer of the article you cited).
Definetely not an overkill. Go ahead and use EF.
It actually depends on the complexity of your data model rather than the type of application it is.
If you have a relatively simple data model, then EF may be overkill (if you don't know it yet). Linq-to-SQL may be a better choice (less learning curve, though it also has limitations such as no many-to-many mappings).
If your data model is more normalized, rather than just table based then EF will definitely pay off in the long run, or nHibernate, or any other more advanced ORM.
The article you link to seems to indicate that ORMs in general are bad, not just EF. When confronted on his points, he seems to back off them to some degree. It seems like he is trying to justify a blanket concept (that new developers should have to learn low level coding, particularly SQL, before going to high level frameworks) by inventing questionable points.
I'm starting a new project based on ASP.NET and Windows server.
The application is planned to be pretty big and serve large amount of clients pulling and updating high freq. changing data.
I have previously created projects with Linq-To-Sql or with Ado.Net.
My plan for this project is to use VS2010 and the new EF4 framework.
It would be great to hear other
programmers options about development
with Entity Framework
Pros and cons from previous
experience?
Do you think EF4 is ready for
production?
Should i take the risk or just stick with plain old good ADO.NET?
Whether EF4 is really ready for production is a bit hard to say since it's not officially been released yet.... but all the preliminary experiences and reports about it seem to indicate it's quite good.
However: you need to take into consideration what EF is trying to solve; it's a two-layer approach, one layer maps to your physical storage schema in your database (and supports multiple backends), and the second layer is your conceptual model you program against. And of course, there's the need for a mapping between those two layers.
So EF4 is great if you have a large number of tables, if you have multiple backends to support, if you need to be able to map a physical schema to a different conceptual schema, and so forth. It's great for complex enterprise level applications.
BUT that comes at a cost - those extra layers do have an impact on performance, complexity, maintainability. If you need those features, you'll be happy to pay that price, no question. But do you need that??
Sure, you could go back to straight ADO.NET - but do you really want to fiddle around with DataTables, DataRows, and untyped Row["RowName"] constructs again?? REALLY???
So my recommendation would be this:
if you need only SQL Server as your backend
if you have a fairly simple and straightforward mapping of one database table to one entity object in your model
then: use Linq-to-SQL ! Why not?? It's still totally supported by Microsoft in .NET 4 - heck, they even did bugfixes and added a few bits and pieces - it's fast, it's efficient, it's lean and mean - so why not??
My advice is use both. At first I thought I would only use linq to sql and never have to touch ado.net ever again ( what made me happy lol).
Now I am using both because some things linq to sql(and any ORM like EF) can't do. I had to do some mass inserts and I did it first with linq to sql and to do 500 records it took over 6mins(2 mins for validation rules rest was inserting into the db).
I changed it to sql bulk copy and now it is down to 2min and 4 seconds(4 seconds to do all inserts)
But like marc_s said I really did not want to fiddle around with DataTables, DataRows, and untyped Row["RowName"].
Say my table was like 10 columns long and called Table A. What I did was I used linq to sql and made a Table A class( new TableA()) object and populated it with data. I then would pass this object to a method that created the datarow.
So linq to sql saved me some time because I probably would have made a class as I would not have wanted to pass in 10 parameters into the method that makes the data row. I also feel it gives a bit of typeness back as you have to pass in the right object to use that method so less chance of passing in the wrong data.
Finally you can still use linq to sql to call Stored procedures and that is like one line of code.
So I would use both when ever you notice that linq to sql (or in your case EF) is slow then just write a SP and call it through EF. If you need to do straight ado.net evaluate what you need to do maybe you can use EF for most of the code(so you can at least work with objects) and only for that small portion ado.net sort of what I did with sql bulk copy.
EF 4 is now more similar to LINQ to SQL, in the good ways; it has the FK keys right in the object, has add methods right in the object sets, and a lot of other nice features. THe designer is much improved, and the major plus is that it works with SQL and Oracle, and maybe some others (as long as the provider supports it) instead of LINQ to SQL with only SQL Server.
EF is the future; the ADO.NET data services is a web service add on, plus it supports POCO and T4 generation, and any new features will support this (LINQ to SQL is maintenance only, and data sets won't be getting any changes any more).
HTH.
I have an existing web app that has a data layer and a bll that calls the data layer. The data layer is ado.net that calls stored procedures.
I created another project in vs.net for linq-to-sql, dragged all my tables over.
Would it be wise to just start using linq or should I spend the time and re-write all the db logic in linq just so I don't have any issues having 2 data layers!
If it ain't broken, don't fix it.
Why would you want to rewrite completely your perfectly working data layer? ADO.NET + stored procedures is a great choice. Keep it. At the same time you can start playing with LINQ.
Anyway, you will need some practice with LINQ to see what it can and what it cannot do before you will be able to decide on the new data layer architecture. There are some situations that LINQ cannot handle right out of the box, so you will need to use tricks or substitute default implementation with your own queries. At the end of the day you may have decided, it was not worth it.
My suggestion is to gain some experience with it separately and not start rewriting everything completely just because LINQ is cool.
Unless your current data layer is broken for some reason, don't just start implementing a new one, just because you can.
Although if currently the datalayer consists of using stored procedures and that becomes cumbersome to maintain, switching to L2S (or any other OR/M for that matter) might be a valid reason. Just don't think it'll be only a matter of dragging some columns to a canvas and be done. Dependent if there's any logic in the sprocs, the logic has to exist somewhere...
I'd say until you can justify the costs of switching your datalayer entirly, stick with your current implementation.
Please be clear: there is a major difference between Linq and LinqToSql. Linq is great and you should be using it if at all possible. LinqToSql is not great and has many problems:
Do not use the Visual Studio 2008 LinqToSql O/R Designer
The drawbacks of adopting Linq To Sql
To use Linq, you need an ORM of some sort. You have many options for ORMs in the .NET world. If you like what LinqToSql offers, you may be most comfortable using SubSonic. In the long run, NHibernate is the best choice for a .NET ORM right now. I wrote a lot more on choosing a .NET ORM here:
.NET and ORM - Decisions, decisions
In the end, there is no reason you can't have two or more different data layer technologies in the same application. There are good reasons not to do this however and so it should be avoided if at all possible.
Also, here's a compelling write-up against using stored procedures:
Stored procedures are bad, m'kay?
I'm thinking through data access for an ASP.NET application. Coming from a company that uses a lot of Windows applications with Client Data sets there is a natural dendancy towards a DataSet approach for dealing with data.
I'm more keen on a Business Object approach and I don't like the idea of caching a DataSet in the session then applying an update.
Does anyone have any experience / help to pass on about the pros and cons of both approaches?
You are smart to be thinking of designing a Data Layer in your app. In an ASP.NET application this will help you standardize and pretty dramatically simplify your data access. You will need to learn how to create and use ObjectDataSources but this is quite straightforward.
The other advantage of a data access layer (built using a separate project/DLL) is that it makes Unit testing much simpler. I'd also encourage you to build a Business Layer to do much of the processing of data (the business layer, for example, would be responsible for pulling ObjectDataSources from the DAL to hand to the UI code). Not only does this let you encapsulate your business logic, it improves the testability of the code as well.
You do not want to be caching DataSets (or DAL objects, for that matter) in the session! You will build a Web app so that record modifications work through a Unique ID (or other primary key spec) and feed changes directly to the DAL as they are made. If you were to cache everything you would dramatically reduce the scalability of your app.
Update: Others on this thread are promoting the idea of using ORMs. I would be careful about adopting a full-blown ORM for reasons that I have previously outlined here and here. I do agree, though, that it would be wise to avoid DataSets. In my own work, I make extensive use of DataReaders to fill my ObjectDataSources (which is trivial due to the design of my DAL) and find it to be very efficient.
DataSets can be incredibly inefficient compared even to other ADO.NET objects like DataReaders. I would suggest going towards the BO/ORM route based off what you are saying.
If you're going to follow Microsoft's direction, then the trend is definitely towards LINQ (ORM) vs. DataSets. When DataSets came into being (ASP.NET 1.0), LINQ wasn't even possible. With LINQ you get type-safety and build-in functions to Create / Update / Delete from the database.
Microsoft has even tried to make the transition easier through LINQ to DataSet.
We're about to do a big update to an existing asp app that used DataSet objects heavily; although I am not looking forward to the pain, I am going to insist on going down the BO route. Just the thought of trying to make datasets work now causes me to break out in a sweat.
I think we are going to go down the LINQ route and use lightweight entity objects.
The company where I work makes heavy use of DataSets as well while there is a business layer as well. BL mainly loads datasets from the DB.
I personally dislike this approach. There is also a practice of direct modifying the datasets after load/before save to meet some immediate needs here and there. To me it really violates the idea of business objects but it's how it is done.
ORM frameworks can really save you a great deal of time, especially in enterprise applications with lots of views with similar buttons and operations.
But it's also easy to lose control. Since that point it will slowly be turning into a mess.
Both options are good when used in right cases. Just don't mix them. Decide to do it one way and follow it.
Mark Brittingham's answer is accurate for two tier applications. But what if I want to use a service tier. DataSets are serializable. Typed DataSets save time over hand coding your own objects. Typed DataSets are extendable. Linq to Entities has performace issues, Linq to SQL is now dead. Linq to DataSet will always be an option.
I will use Typed DataSets and a multi-layered architecture to save time and organize code. I've tried hand coded BOs and the extra time and maintenance time is not worth it.