I am developing a application with asp.net 4.0. My site will be a heavy like more then hundreds of user will be online at a time and lots of content will be there. I have checked both ado.net entity framework 4.0 and Linq-To-SQL with Microsoft.NET Framework 4.0 both are having great improvement over there. I am confused that which one i should use. Performance is one key aspect of my application I don't want to degrade performance of my application via making a bad choice. Could any one will help me on this? Any link or any suggestion will be appreciated.
Thanks in advance for any tip.
Google is your friend. I'm sure that you can find a lot of those threads.
Only you can tell which technology you want to invest in, but it's worth noting that Microsoft is investing the VAST majority of its effort in Entity Framework. Linq to SQL is being maintained, but is not getting anywhere near as much attention.
EF4 is a huge leap forward compared to prior versions of EF. The introduction of "Code First" is, in my view, a significant reason to adopt EF over Linq to SQL.
I'd recommend to chose the one that you can play better with, from maintenance perspective. In many cases we have based our decision on the factor of the team capability. If most of our team members have enough experience and exposure in X technology or tool, we'll prefer that over another. This way you can maintain your software without stress and also deliver reliable solutions to your customer in less time.
Related
I am looking for a reporting and database contols solution. This post is not a rate the control but what has your experience been when using it.
I had a look at Telerik, DevExpress, Syncfusion and a few others. I have downloaded a copy of each and tested each for a week or so. However these arent cheap when I make the investment I would like to base it on othera experience as well as my own feel for the tools.
I had read all the post on SO and many other sites. Many outdated so wanted to know more recent experiences.
DevExpress looks great and seems to be what im lookig for however from what ive read their controls are coded and very differet ways. WPF is apparently very bad. I could be wrong though and please correct if i habe been misinformed.
Everyone seem to be happy with Telerik.
I will probably be customising later on so source is important. Winforms will be used. But would like to migrate to WPF and/or ASP.Net later. This is client requirements.
thanks in advance
You should list down your expectations from a third party suit.
Also its better to compare individual components rather than the whole suit.
I have lot of experience with devexpress#winforms, but the learning curve is quite steep.
I don't like the layout controls. Rest of the controls are pretty slick. Reports and Charts are good.
Support is also quite good.
I'm working with DevExpress scheduler for WinForms right now, and I can say only praises for this component suite. Everything is accessible easily, customizations are very easy; but to be honest I still haven't done any major customization, so it could be possible that 95% cases are easy, but that 5% is impossible (not sure, don't have that much experience with DevExpress). I would just say that they are much better than Infragistics WinForms suite.
Also reporting suite (XtraReports) is well known as a very good solution.
I have recently made the shift to a framework called the Yii Framework. Really is good to be working on a framework, solves lot of mundane work. I believe the framework will provide me the platform to build a great site but a senior developer keeps asking me these questions.
How many concurrent users can the site handle?
Is the site scalable?
What is the performance level of the website?
If you were to answer those questions about your project how would you do it?
and also how would you tackle the scalability issues once and for all.
P.S. Any references i could read upon will be greatly welcome.
Scalability is not a hole that one can plug. It is a very broad and generic topic in itself. One of the best approaches I've seen is that of youtube
while (true)
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
Having said that, database is usually the bottleneck in most of the web applications and the choice of web framework doesn't matter much. Things like number of concurrent users and performance levels will be sufficiently large for most of the frameworks.
While this answer is quite late, I hope it helps you in your future projects.
You should not look at scalability as a bandaid or a one time fix.
As the usage of your application changes, your scalability requirements will change and evolve. Also, there is no silver bullet for addressing scalability. It is a mix of various approaches like caching, replication, distribution, performance tuning, hardware upgrades etc. You should choose from those based on the context of "what you want to scale" and where will you get maximum bang for the buck!
check out this link
http://sevenoct.wordpress.com/2013/07/04/scaling-applications/
which has some good information about scalability and how not to fall into traps of "sought after" scalability mantras
In my company they are finally (about time...) considering to convert one of our best selling apps from a 2-tier to 3-tier architecture, both on logical (Presentation, Business and Data layers) as well as physical level. Probably we will go for either a Delphi-Delphi-Oracle or a Delphi-Java-Oracle approach for the change.
This is a relatively old and large app that has been created and modified for a long time before I began working there. Refactoring, except for when something had to be changed, was usually never considered. Also, business logic is present in both of the actual tiers... sigh.
The physical change does not bother me much but the logical change will be kind of a passage through Hell. In order to smooth it as much as possible I would like to investigate about which Delphi components suit better for a 3-tier model.
¿Which alternatives would you consider to use?
Another good n-tier framework library is kbmMW from components4developers: http://components4developers.com/
We've recently converted our 2 tier Delphi app to 3 tier using RemObjects DataAbstract. While the initial learning curve was quite steep, we are absolutely delighted with the results.
DataAbstract lets you forget about the underlying nuts and bolts of database and network connectivity and concentrate on the business logic. It allows you to create an abstract service layer that provides your server clients with a nice API. Using this API we connect to the server using both a Delphi and a Delphi Prism ASP.NET client.
I've found RemObjects pretty usable. They have also DataAbstract built top on it, but I haven't used it.
Have you ever considered DataSnap XE?
Back in late 2008 there was a lot of debate about the future of LINQ to SQL. Many suggested that Microsoft's investments in the Entity Framework in .NET 4.0 were a sign that LINQ to SQL had no future. I figured I'd wait before making my own decision since folks were not in agreement.
Fast-forward 18 months and I've got vendors providing solutions that rely on LINQ to SQL and I have personally given it a try and really enjoyed working with it. I figured it was here to stay.
But I'm reading a new book (C# 4.0 How-To by Ben Watson) and in chapter 21 (LINQ), he suggests that it "has been more or less deprecated by Microsoft" and suggests using LINQ to Entity Framework.
My question to you is whether or not LINQ to SQL is officially deprecated and/or if authoritative entities (Microsoft, Scott Gu, etc.) officially suggest using LINQ to Entities instead of LINQ to SQL.
For all the "Linq-to-SQL is dead" folks: Scott Guthrie himself clearly mentioned at TechEd Europe that Linq-to-SQL is FULLY SUPPORTED in .NET 4, and Damien Guard posted a blog post on what changes and improvements have been made for Linq-to-SQL in .NET 4.
To quote Mark Twain: "Reports of my death have been greatly exaggerated"......
Last I checked, this very site uses (or used to use) Linq To SQL. Joel Spolsky mentions this in his GoogleTechTalk: http://www.youtube.com/watch?v=NWHfY_lvKIQ.
When speaking of software, "dead" is a figurative modifier (software doesn't die in any literal, biological sense), so this debate can linger on as long as the involved parties refuse to define in any literal sense what it means for "Linq To Die". Or, LTD for short. Hence, as of this moment, the LTD debate has lingered for two years. All because of a little linguistic ambiguity.
Those who say that "L2S is dead" are generally referring to the fact that L2S isn't going to receive too many (if any) new features. Updates to Linq (like the updates mentioned in Damien Guard's post) are likely to be confined to performance, usability, and stability updates. Of course, some developers might actually argue that this is a good thing (probably the same developers who are a wee bit angry about the new dynamic type).
Those who say that "L2S is not dead" are generally referring to the fact that L2S isn't going to be cut altogether from .Net (at least not anytime soon). Think: ADO. It may lose some of its traction amongst practicing developers (and that may be the unspoken desire of those crafty folks at Microsoft), but that doesn't mean that you won't be able to use L2S if you want to. It just means that Microsoft isn't trying to tantalize the masses with it.
When starting a project, I actually think it's great that I have a choice between EF and L2S. As Bill Wagner points out, there's a time and a place for both.
I am late to this discussion, but I wanted to point out that as far back as 2008, the Link to SQL Project Manager (Tim Mallalieu) made this announcement in his blog post,
"As of .NET 4.0, LINQ to Entities [rather than LINQ to SQL] will be the recommended data access solution for LINQ to relational scenarios."
I have found no other more recent announcements to the contrary.
No it is not. The team are still working on improving it.
LINQ to SQL tools in Visual Studio
LINQ to SQL was the first object-relational mapping technology
released by Microsoft. It works well in basic scenarios and continues
to be supported in Visual Studio, but it's no longer under active
development. Use LINQ to SQL when maintaining a legacy application
that's already using it, or in simple applications that use SQL Server
and do not require multi-table mapping. In general, new applications
should use the Entity Framework when an object-relational mapper layer
is required.
Make sure to have a look at this article posted on InfoQ.com - it's a really interesting one. Its conclusion: "[O]ver the long run LINQ to SQL and LINQ to Entities will merge. In the mean time, development work on LINQ to SQL will not end entirely."
i guess it's inevitsble that they'll merge. EF is really an enterprise level implementation of LINQ over db objects. linq2sql was to all intents a proof of concept(and a lot more) that actually grew legs but fuelled many of the ideas that we now see in EF. at the end of the day, the DAL layer (nhibernate, EF, l2s, subsonic etc) should be pretty far down the chain so as to negate any differences in the client BO code that implents the LINQ service - hot swappable would be the end game via DI.
Incase if you are to develop twitter today what language, tools and approach will one take. How will he start from the very frugal configuration and gradually scale to the levels twitter has reached today. Incase if you can provide direct responses like (PHP+ Apache+ memchached+ MySQL) or (JSP+TomCat/Glassfish+ MySQL / other db) etc.
The criteria is an architecture which scales easily without much engineering and the right language so that one doesnt need to rethink his decision once the same is in place.
(As far as I know, Twitter is RoR, Linked in is Java and Digg in Php. So not looking for just random thoughts :) ) Do support why do you think your option should suffice.
Thanks
As you already say it, there are several applications that shows that several technologies are able to scale. Fortunately for them.
I think you should not focus only on "is this technology the best for scaling". But on the two following points :
Do you have skills in that technology ?
Is that technology adapted (by it's philosophy) to that application ?
Scaling is a thing. But if you can't develop your application with the "killer" technology because you don't understand it, it's anyway useless.
I recommend looking at the High Scalability website. You can build a scalable web app in virtually any language, but it's not just a matter of using the right technology and then plugging it in. You have to know what you're doing, no matter what technology you use!
Twitter was developed using the framework Ruby on Rails (ROR), and that seems to be a good choice. Ruby on rails is database agnostic (supports most databases), very scalable and very good for developing web applications quickly.
Cake is a popular alternative for PHP I haven't used Cake but hear it is very similar. The alternative to these open source alternatives would be a full blow enterprise environment like the microsoft .NET frameweork.