I have an asp.net web forms application that uses linq 2 sql. A lot of the controls are databound to linq datasource controls.
I want to clean up this application so I can easily use html5's offline functionality.
I thought I should probably move my linq 2 sql statements from code behind to classes and then call to the class. Not sure?
What I would like to do, is have a clean separation and since MS is no longer promoting linq 2 sql, I would like to move to linq 2 entities.
Eventually, a while from now, I would like to convert this app into mvc, but one step at a time.
Would it be better to just make separate data classes for each form or just create database first linq to entity classes?
Thanks,
Sheri
I would recommend reviewing the Repository Pattern suggestions here. I've been using the Repository Pattern with LINQ-to-SQL and ASP.NET MVC since 2009, and it has been very good for me for managing my data interactions, maintaining separation of concerns, and, especially, testing.
Related
I'm creating a lightweight database to rent movies.
I really like LINQ, so want to stick to that. My forms need validation so that is a requirement (ComponentModel.DataAnnotations).
Is there a model tool/template/thingy that combines them all, giving me the opportunity to create classes, generate them to the database (like the ADO.NET Entity Data Model), giving me LINQ (like LINQ to SQL Classes) and form validation (letting me implement ComponentModel.DataAnnotations)
Simply use Entity Framework - it supports all you need. Check this ScottGu's article for more info.
I have a small application developed in ASP.NET 2.0 WebForms. For learning purpose, I am thinking to convert this application to MVC 3 + Entity Framework. Below is the simplest example to simulate my application. Nothing fancy.
Application Layout:
(image should read "input fields" and not "files")
Architecture:
Key points:
Methods in Service layer is using ADO.NET SqlCommand ExecuteReader method to execute stored procedures
Most of the manipulation etc. logic is done in stored procedures. Hardly any manipulation of data in Service layer
Now I want to convert this application to MVC.
Questions:
What benefit do I get (technically) if I convert this application into MVC + Entity Framework?
How do I go about it?
I have looked at some basic MVC3 tutorials but they all talk about EF code-first, which I don't think will fit in my case since I want to use the existing stored procedures. Is that correct?
Note: I want to use the existing stored procedures. Say I don't have control on DB structure changes.
Update 1:
There isn't a single inline query in my application. Even the smallest little query is a stored procedure. Tons of them.
Using SQL Server and almost nil chances of changing to any other DBS.
Update 2:
My webforms application is 99% complete and can go live anytime but due to some business hurdles it hasn't. In mean while I thought if I can convert (i.e. develop) this to MVC, I will learn plus if it works out can go live (my first MVC) instead of the webforms one.
Before answering the specific questions I'll point out that you should probably seperate the choices into 2:
Converting the presentation layer to use MVC instead of WebForms.
Converting the data layer to use EF instead of ADO.NET.
Now for your questions
Benefits of MVC include better control over HTML, better testability, etc. Benefits of EF include abstracting away DB-specific things (you could theoretically replace SQL Server with MySQL, assuming an appropriate MySQL provider), LINQ support, etc. Of course there are also costs to such a transition.
Divide and conquer. As stated earlier you don't have to do everything at once. Start with the presentation layer and convert it to MVC. Remember that you can have mixed WebForms and MVC applications so you don't have to transition all your pages at the same time. Then convert your data layer to EF. Or start in the reverse order, whatever makes sense for your project.
[Not an expert in this topic] if you rely heavily on SPs than consider traditional EF. If you have only a few SPs then you could consider code first + handling the SPs with DataSets (potentially wrapped in custom built classes) to make everything work, though that might get complicated. As before, you don't have to move to EF if the cost is too high.
What benefits do you get? It is completely wrong question. You should ask what problems do I have with current solution and how will these problems be solved by replacing data access with EF or replacing presentation layer with ASP.NET MVC?
As I understand you want to do this just for learning purpose - it has no business drive. In such case there are some points which will get you some ideas:
If you don't want to replace existing SP logic with the common EF way you will get almost none benefits and you will not learn EF. EF allows using stored procedures either for retrieving mapped entities or for loading custom classes. Mapped entities usually represent either views or tables from the database - it is not clear here if you even want to define any mapped entities. The only benefit you get when loading custom classes is automatic populating of properties from the result set. It means that you will need class for each SP result which will have properties named exactly the same as columns in result sets. SPs in EF doesn't support multiple result sets (by default) and also doesn't support automatic loading of relations.
When moving from ASP.NET Web Forms to ASP.NET MVC + Razor you can be almost sure that non of your front end code will be usable in the new solution. You will simply create new project and do you front end from scratch.
As described by #marcind these two changes are completely independent - you can do one without other.
Say you had to quickly build a data-entry UI that works in a web browser, which must interface with a business layer, which must interface with a data layer.
You want to connect only to business objects, not directly to the database.
Most of the views of the UI will be simple CRUD operations, with edit/update happening within a grid.
But some of the screens will be more complex, representing many-to-many relationships.
What's the fastest way to achieve this in ASP.NET?
(Note: speed of development is high priority, code quality and re-usability are low priority.)
Entity Framework + ASP.NET Dynamic Data?
If speed of development is the main priority, then go with what you know.
For example, if you know ado.net/enterprise library then go with that. If you know Entity Framework or LINQ, then go that route.
Without a summary of your skills, it's going to be impossible for anyone to tell you the fastest way to get something up and running.
I've written a lot of little business editors like this for my company in the same manner, get it to work quickly, if it's used or needs to be improved, I deal with that later.
Start up a new asp.net project. Add a class library to the solution and reference it from the asp.net application.
Asp.Net Application
Use Master Pages and Themes
Use a repeater for the data lists and command buttons for selecting and deleting.
The repeaters work well for inner lists as well, take note of OnItemDataBound and OnItemCommand.
Use Panels to hold the lists and editors, write some logic to control when to view editors and when to view lists.
If the logic is common, then make some base pages that new editors can use and override.
Class Library
Add your business objects
Add a Linq to Sql class and add database objects as necessary.
To make it simple, you could use the some of the time tested controls and objects:
User Interface Layer: GridView for displaying and providing links for editing and deleting data. Clicking on Edit link may open up a new Asp.net web page that holds FormView for inserting and updating records. Use ObjectDataSource to link methods at the Business Logic Layer to Create/Read/Update/Delete records.
Business Logic Layer: Apart from creating CRUD methods, you might need to use light weight serializable data transfer objects to pass data between different layers and a custom mapper to trnaslate data from and to other layers.
Data Access Layer: Linq to Sql might make the data access and manipulation quick and easy.
It depends on the complexity of the application. I would go with Linq to Sql. But then using Linq to Sql does not necessary provide a good abstraction between the business layer and the data access layer. But I find that using Linq to Sql you can quickly retrieve the data out of the storage and display it on the screen.
Also, if you want fast UI then take a look at dynamic data website. That also uses Linq to Sql or Entity Framework.
One question you must think is that if you need good design or RAD.
I just started working on an asp.net / C#.net application that is going to call a number of different procedures. The -only- thing these procedures do is create database table views, and the only thing I want to do is to store the information in variables. Then pick out which columns I want to convert to JSON, and then make a JSON string. I've actually written code for that in C#.net already, which is smaller, but since I switched to asp.net mvc I'm a little unsure if I should keep it or go with the whole Linq thing.
I checked out the Linq --> SQL drag & drop functionality, and that instantly created about 200 lines of code with set & get methods and everything.
So my question is, is it still worth using Linq even for just extracting data? Eventually this data will be fed to a javascript timeline, which is where I was told MVC would be highly useful with regards to Ajax functionality.
Since you are only using LINQ-to-SQL for data retrieval, I can't think of a single reason NOT to fully utilize it. I've been working on an MVC 1.0 project since last April. During that time, I've had to quickly become familiar with a number of technologies, LINQ-to-SQL being one of them. Get comfortable with it, and also look at the repository pattern...you will be very content and things will go relatively smoothly.
Now, when you get to INSERTs and UPDATEs, things are going to get a little more sticky. LINQ-to-SQL is still up to the job, but you'll need to understand how things work internally a little better. I highly recommend "Pro LINQ (Language Integrated Query) in C# 2008" by Joseph C. Rattz, Jr. The sections covering LINQ-to-SQL easily take up over a third of the book with detailed examples.
As far as the JSON objects go, LINQ-to-SQL's biggest contribution is that it allowed me not to have to worry about creating specialized views or stored procedures just to handle those one-off-types of data retrievals. My current project has a database of 65 tables...NO stored procedures. I can do filters, unions, multi-level joins...and it's all maintained in the application. Sweet...
Yes, it's totally worth it!
LINQ2SQL provides you a great subsurface to retrieve and save data to.
However, you'll need to implement your own Repository Pattern as you dig deeper into ASP.NET MVC.
And during the implementation of the Repository and the required (and even custom / webapp-state based) Queries, you'll be very glad to have all the power available at your fingertips that LINQ provides.
LINQ only adds to the available toolkit you can lean on when creating code. Even if you are using LINQ in a trivial way now, implement it, get familiar with it, and take advantage of the power it gives you both on this project and future projects.
Linq2Sql is quiet good for creating select queries. As it is appearing that you need to create JSON objects from database views it will be quiet useful
I am develop a medium system in ASP.net with MS SQL Server Database and I wonder what is the best way to create a model layer with LINQ or create own classes that dealing with database?
The best way is subjective, but I think the easiest is to use LINQ to SQL.
Using the LINQ designer is a great way to build your model in a UI avoiding the need to write any code. You can setup object hierarchy using the inheritance option and also have associated classes which you can access via the datacontext in code. All of the SQL is then handled for you and means you don't have to write anything, simply call SubmitChanges() on the datacontext. All of the generated code can be viewed, but there is a lot to take in.
I would suggest to try writing your own classes manually with the LINQ attributes etc so you get an idea of what it is doing behind the scenes. Then you will realise how the inheritance and association is implemented and actually makes the designer easier to understand too.