I have a webstore which sells components (it is a academic project) which looks like this. I have developed the same web application using following database technologies:
MS Sql Server with Stored procedures and sql data reader
LINQ to Sql
DB4o using LINQ (Client/Server)
What features can I compare apart from the technical and theoretical details between relational database and object oriented database ?
It is my graduate/master's thesis final project. I want the features that i want to compare to be more practical and interesting so that I can draw some concrete and meaningful conclusions rather than abstract comparisons which don't create much interest and hard for inference.
Please help me.
Feel free to express your opinions.
Thanks in anticipation
PS: Don't downvote or flag this post, if some one doesn't like this question u may delete it after getting answered
Here is a site that compare DALs, maybe you can get some ideas for what other think you can compare.
http://ormbattle.net/
Also here is my first question on StackOverflow that I compare 4 dals for speed and optimization.
Benchmark Linq2SQL, Subsonic2, Subsonic3 - Any other ideas to make them faster?
What features can I compare apart
In you case I was try to compare the speed, and if the conversion to a DAL can give the same or more features that can get with out it. For example, can you get all the same questions that you can do direct with SQL or not, and what is the limitations.
Try creating some performance benchmarks and do a side-by-side compare of the three different DB technologies (these are not methodologies) for given types of queries.
Related
I am creating my application in asp.net 3.5. I have to make my Data Access layer, in which I am doing the traditional method of fetching/updating the data. Which is SqlConnection than SQLCommand, than SQLadapter.
Will there be any other way I can create my DAL layer easily.
Specification.
My website is small. Approx 7-10
pages.
Database has around 80
tables.
What I know:
Linq to SQL - I don't want to use it
because I am not fully aware about
the LINQ statement and I need to
develop the application really fast.
[3 days :-( ]. Also, there are 100%
chances that the table structure
will be altered in future.
Enterprise Library: It will take too
much time for me to integrate to my
application.
Any other suggestion to create my data layer, quick ... fast ... and "NOT" dirty.
Thanks in advance.
How about using Codesmith (free version 2.6) to generate a simple set of data access objects off your database? Given the small number of DB objects that you need to model I think this would be a quick and easy way of achieving your goal given the time constraints.
I would have recommended using LINQ to SQL. But, since that is a no from you, only other option I would suggest is Strongly Typed Datasets and Table Adapters generated by Visual Studio. They are old but decent enough to work in any modern application.
They are fast to create. They provide type safety. They are quite flexible for configuration and customization. Since they are generated by Visual Studio, any changes made to database can be easily reflected quickly.
Being a LINQ beginner myself, I would recommend taking the plunge and going with linq-to-sql or entity framework. I cant say for certain without knowing your requirements but theres a good chance taking the time to learn basic linq for this project would speed up development overall.
You may also want to consider SubSonic. It's relatively easy to implement and is fairly intuitive to use. Used it for the first time recently on a small project, and despite some initial configuration problems getting it to work with MySQL, it handled data access pretty well.
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 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.
What is the easiest way to write user entered measure values (sales forcast) to the SQL Server Analysis Services OLAP cube from a .Net client application?
I'm aware that underlying fact table can be updated with DML statements and that cube can be reprocessed but I'm looking for alternatives.
Regards,
Aleksandar
We use pivot table Ranet OLAP for editing cube data.
View sample Simple PivotTable Widget - PivotTaple with Updateable
Writing updates to OLAP cube.
I nearly got into a project like this once. It did not go ahead, which I was very grateful for, after looking into the work involved. My advice to you is to run away!!!
You do not have to update actual cube data, or reprocess though - depending on how complex your user-entered data is going to be. I believe this is covered in Microsoft's standard MDX course, the notes of which you may be able to find online (sorry, I've since disposed of my copy). This depends on whether you want to learn MDX though, which is not easy.
I think you can use ADOMD .Net to do Writeback. You can ADOMDCommand to wrap UPDATE CUBE Statements.
ADOMD .Net
http://msdn.microsoft.com/en-us/library/ms123483(v=SQL.100).aspx
Link below talks about some of the issues in this approach, if you are doing too many updates together.
http://www.developmentnow.com/g/112_2006_1_0_0_677198/writeback-in-ADOMD-NET.htm
I have looked at NHibernate and EntitySpaces and they both seem to work differently.
In EntitySpaces, you define the database tables and table relationships and the classes are generated for you.
In NHibernate, you define the classes and the table relationships are generated for you. This is what I am looking for.
Are there any other ASP.NET ORMs that generate tables from classes like NHibernate?
Any recommendations?
DataObjects.Net also uses "Code first" (Model first) approach.
See http://wiki.dataobjects.net/index.php?title=Features
Linq to SQL can create the database table structures and relationships from the classes, with the dataContext.CreateDatabase() method.
Mindscape LightSpeed offers this ability - part of complete scheme round-tripping.
Hope this helps
http://www.mindscape.co.nz/blog/index.php/2008/06/17/schema-round-tripping-in-the-lightspeed-designer/
I prefer an approach that I have full control to generate what I need as well. In the case of ORMs I get classes that match my tables. I believe that using my own domain of objects that derives from my business and not the underlying data store is the right way to go. My class hierarchies that represent my business data should be 100% independent from the data store.
LightSpeed has a really good Visual Studio designer that supports both generating .NET entity classes from the database and updating the database from your .NET entities.
This is something that NHibernate does.
And on the subject (that Draemon) started. My personal view is that unless performance is your absolute 1st priority and all other things must suffer to make that happen (e.g. when writing software for a manufacturing fab), you will be better off working on the domain model first.
My reasoning: you spend a lot more time coding against the domain than you do against the database itself -- especially when using an orm. So spend that time wisely.
I had fairly good success working with Genome ORM. It does many jobs for you. You can first design your domain model and then generate the DB scripts out of that. Beside this Genome generates DTOs for you. It is pretty good at that and saves a lot of time of developers.
http://www.genom-e.com