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.
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.
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.
I am a student and in last semester i develop asp.net application - "Payment Helper for School" . In this new semester i will have subject "Graduation Project" and i thinking about develop my application.
In my old app i use:
ASP.NET web forms
mssql 2008 database
linq to query to db
I achieved technologies above at good level and i want learn another one - WPF and XML cause i see that employers demand these and to create "cheaper" data layer ;)
I think to use in new version:
WPF forms instead of ASP.NET
XML (XSLT etc) instead of MSSQL
i stay in linq to XML
Do You think that this is good develop of my app? I am now learning WPF from tutorials, but i want to learn it at practice. I think also about NHibernate which interesting me, but it is too much :/
What advice you can give me at developing app rely on WPF and XML db ?
Doing this would move your application from web based to windows based. Think of WPF as winforms.
If you want to keep this application web based, you could look at silverlight, its a subset of WPF.
I wouldnt change your storage layer from SQL to XML if the app is data driven. Otherwise your going to have to handle concurrency, file locking etc which SQL server does for you by default (row locking etc) Ie, if there is lots of writing / updating of data SQL server is a much cleaner option than XML. In this context, think of XML more of a language independent way of passing data around, and storing simple data structures that are primarily read only.
If this is a graduation project, perhaps focus instead on design methodologies, MVC, or MVVM if you do choose Silverlight. A plus for potential employers and plenty of depth for a dissertation.
Edit - id argue XML would be a more expensive data layer! For the reasons above its going to be more complex and therefore greater dev time. Additioanlly SQL server express is free and the advanced edition with full text search and SSRS is also free; we have loads of clients that use it.
Edit 2 - another option would be to use Flex. It would be a completely independent tech on the presentation layer (and from a Uni point of view this could be good as you may loose marks / not even be allowed to use stuff from a previous project) Then you could use a combo of XML and JSON to pass data between the Flex layer and .NET on the server. Just another thought for you!
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.