I have been asking my self this question from the time i started workin in the software development field,
What is the best way to access data?
Which gives the best performance?
Which is the best for maintainability?
There are lots of solutions to deal with database in the Asp.Net web app,
Entity framework 4.0
Classes generator using ADO.Net such as Code Author ( i liked the way it works and the way it accesses the database using the data access block in Microsoft Enterprise Library).
i will start a new project tomorrow,and i don't know which approach is better??Any idea?
I'm using Castle Active Record for data access in our new ASP.NET project. It's a great and easy tool that is built upon NHibernate. NHibernate itself is a great ORM for .Net.
There is no "best". There is only preference. Some like MVC, some like WebForms, some like Dynamic Data. Entity Framework works nicely, as does LINQ to SQL(although I hear that one is being deprecated, but I'm fuzzy on that.) All work well.
Personally, I like WebForms, but if I want a quick and dirty CRUD app, I always opt for Dynamic Data, and if I need additional functionality mixed in, I can throw in some standard WebForm aspx pages.
Performance wise, I don't know that there's inherently a big difference. All use the same code under the hood. All are based on ADO.NET. Entity Framework and LINQ to SQL seem to have additional overhead compared to the old-fashioned WebForms, but proper DB design and planning is probably of greater importance.
Related
I have ASP.NET project and I want to know what is better to use.
ODBC connection and with Server Explorer (drag and drop make DataSet and modify it) or do some DBconnect class with connection to database, queries and use it for GridView?
When I use server explorer, I don't have good feeling because all logic is on aspx page and I do not separate from the application layer logic layer.
It will be a lagre application, databese(PostreSQL) have 18 tables and difficult constraints and application have to generate some documents etc. .
"Better" depends entirely on your situation. Is the purpose to get something done as quickly as possible for internal users at your company, or is this going to be a commercial site that will need to be highly extensible and needs to be as easy as possible to maintain? Will you need to integrate with other platforms possibly built using other languages at some point? The answers to all of these questions should affect your decision.
If you're looking to separate your project into distinct layers, then I would recommend an ORM such as NHibernate or Entity Framework (there are other commercially available ORM products out there, but these are the ones I'm familiar with and which you can easily get help with on this site).
Create a DataSource with LINQ to Entity. It let you the liberty of LINQ with the peace of mind of when you change something il will break your build so you will be able to debug more efficiently.
Well if you have total flexibility, I would recommend using C# ASP.NET 4 with MVC3 razor for the UI and application code. Use Entity Framework 4.1 code first for the data access layer.
This way you will always work with real objects that you create, and with List<realtype> instead of the total mess that exists with datasets.
Can anyone tell me what the future is for asp.net dynamic data? It seems like it is being put aside in favor of MVC. Is it worth investing time in dynamic data applications?
Without branding, Dynamic Data applications can be created in minutes. It for your RAD webform developer who doesn't care about the UI layer. This would work well for just about intranet scenario. However, the MVC lineage is geared toward very different scenarios.
The Asp.net dynamic data entities web application compounds several layers into one. I know that Object Relational Mapping (ORM) is supposedly the future but when layers are not exposed, it can cause serious optimisation issues as well as making testing almost impossible. This is the case with both the ADO.NET Entity Framework (EF) model and the LINQ to SQL model. These are the only out of the box model providers availabe to Asp.net dynamic data entities web application. These do not work well, if at all with Microsoft Access.
However, when there is little time to architect a proper solution, Microsoft are ingenious when it comes to dirty ways to write applications. The dynamic data entities web is one such technology to add to their bow. You might be prepared to architect a Sql Server database roughly because you anticipate having to make changes to it later. If you want a quick know around website that you want to rip out later when you have more time Asp.net dynamic data entities web applications are for you? EF goes as far as foreign keys to definite relationships.
Looks like it will die on the vine to me.
Reference to my work before, asp.net dynamic data help me build a "quick + easy" data edit grid to user. I can customize the grid, configure to display what data to users.
But actually, aims of asp.net dynamic data is not purpose to do this.
On ASP.NET MVC 3.0, webgrid can generate by strong-type model with List or EF4.0 edmx ,it can do similar with asp.net dynamic data, so in my opinion, asp.net dynamic data has no future.
I am learning ASP.NET MVC now a days and I have found that most of the examples in ASP.NET MVC are with ORM. I don't have any issue in using ORM for my learning and personal project. But at my work we have worked only with ASP.NET web forms and we use stored procedures only. We have data access layer (simple c# classes) as interface between asp.net code behind page and stored procedures. Now if we want to use ASP.NET MVC, will it be a bad idea to do it without an ORM. As most of the MVC frameworks like rails/django have built-in ORMs, is it any harm to use our own data access layer with ASP.NET MVC. I don't want to have any database related activity like datareader, datatable in my controllers. Is there any other better solution?
If you have a DAL already built - use it! Unless you were planning on moving from your existing DAL to an OR/M anyhow you won't find it beneficial to move to an OR/M for it's own sake.
One of the beautiful things about the MVC pattern is the is encourages a separation of concerns. This means that you are reducing coupling in you application which makes your application's architecture flexible and modular. This means that if at some point you want to swap out your existing DAL for a more modern OR/M solution you can do so with minimum impact to your application.
No harm at all. ASP.NET MVC doesn't require ORMs but you should have models (that might not map to your stored procedures 1:1) of the data your views and controllers can deal with.
You can roll your own ORM if you like even. ORMs are around to make things quicker for development so that you can easily map your database data to object models that you use in your application. You can map ORMs to stored procedures as well.
I personally perfer to use stored procedures and map the results to object through my own data access layer as it gives me a lot of flexibility. This is a personal preference though and there is no right / wrong answer.
Model View Controller is a framework to help provider a clear separation of concerns between the tiers of an application. The Model can be any form you wish really. ORM is not always appropriate, if you have some other DAL in mind then use it. Direct data access with the repository pattern works well, this will help you hide the logic you do use to access your database and allow you to change it later down the track with much more ease.
I am going to make an web application where a lot of users are going to input data into a SQL Server with ASP.NET 3.5. There will be no heavy load of data sent to the client as data will be set to pagesized from the database. Stored procedures are used.
I am asking you guys with experience in web 2.0 aka AJAX, jQuery and other client technologies ( no postbacks ) about performance and responsive matter. I have also looked into ASP.NET MVC, but most examples shows either in LINQ to SQL or with the Entity Framework. LINQ to SQL seems to perform slower than the ordinary ADO.NET. I prefer to load data to objects.
Insert and edit forms are to be opened on the same page with javascript, either through modal pop-up or in an area reserved for it.
Preferably a solution with minimal coding.
What do you suggest?
Reading your post I see the following requirements/desires...
System will be under decent to heavy load, minimal coding, Stored Procedures, load data to objects.
Sounds like an ORM will be a great solution. It may perform slower than raw ADO.net calls BUT you will greatly minimize coding and you can use Stored Procedures in L2S and Entity Framework and they both can work well under stress. For example, this site uses L2S. :)
The use of the ORM should also reduce your development time since you won't have to write all of the database access code.
You can still load data to objects by keeping the L2S or Entity Framework as a layer in your application that just does the raw DB access. You then create another layer that calls this to populate your objects with the data but you can control how to design those objects and how they work. In fact this is a recommended approach. Here's a link that shows how you can create a tiered approach. :)
http://weblogs.asp.net/dwahlin/archive/2008/02/28/building-an-n-layer-asp-net-application-with-linq-lambdas-and-stored-procedures.aspx
As for your client technology with MVC, AJAX, jQuery, etc.... they are fine choices and with MVC you have complete control over the HTML and no viewstate to worry about as compared to Web Forms.
There's a lot here to answer and not everything has a definitive you should do XXX and not XXX. Let me try to break it down.
ASP.MVC vs WebForms (standard ASP.NET)
You can make a decent data entry application using either platform. Webforms has been around longer and definitely has more coverage through tutorials, but ASP.NET MVC is just as capable. MVC is going to be leaner and meaner, which is good if you are going for pure responsiveness, but it's possible to do that with Webforms too, it just takes more work (turning off ViewState, SessionState, Minimizing postbacks etc) and removes some of the benefits of Webforms.
Data Access
If you have already decided on using stored procedures as your primary data access method, you aren't going to get much of anything from any ORM (Linq2Sql, Linq2Entities, NHibernate, Subsonic, etc). If you really want to leverage the benefits of ORM you will have to give up stored procedures for your primary data interface.
However, Linq2Sql is considered plenty fast. Linq2Entities is a bit slower, but that will probably improve. NHibernate and Subsonic are slower still. It's not very useful to compare any of them to ADO.NET since they do very different things (that happen to revolve around talking to a database). But all of that is pretty meaningless as the slowest part of any system is going to be sending data across the internet back and forth to the user.
Have you checked out Asp.net Dynamic Data Project that makes it rather quick from start to a working app. You would then tweak those things that you need to change. But you will maybe have to get to know some new technologies to get it done. Maybe Sps won't be in your end solution.
Definitely minimal coding involved.
I am developing a applicatin which are having more than 5000 users once upon time. I using
ASP.NET 3.5 framework for developement. I want to develope a high performance DAL Layer
using latest technolgies like linq,ADO.NET Entity,ADO.NET Data services. I also want to make sure that it shuld be generic to all the future developement. Can any one pleasae Let me know which pattern i should use to develope that Database Access Layer. I am also
want to use microsoft enterprise library for that.
I think you should look at NHibernate and Fluent NHibernate.
You could save yourself a lot of time by not writing your own DAL. Only you know your non-functional requirements around perf and whether you're optimizing for reads, updates or something else, so write some tests, prototype, and see how it goes.
My personaly opinion is that Microsoft Ent Lib and perf aren't best buddies, but again you should prototype and prove this early in your dev cycle.
You can use Linq to SQL.
You can also take a look at this article series for creating an actual DAL using the same technology.