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.
Related
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.
I'm attempting to setup Entity Framework using Code First on an existing database. The database isnt in great shape (poor naming convention and some constraints are needed). The application I'm building is an MVC app. I have a "Model", "Repository", and "Web" (mvc) tiers.
To setup EF and map my model objects (POCO objects), is it required that I match my objects to database tables? Can I, instead, use my own stored procedures for CRUD operations? Would it help if I use WCF data services?
I'm planning on using fluent configurations to map my objects, but having some issues due to the database schema. I'm know considering redesigning the database just to get EF to map correctly. Any suggestions would be greatly appreciated!!
Looks awfully similar to this question:
Does Entity Framework Code First support stored procedures?
The answers there may be helpful to you, as well as the discussion surrounding how Code First and Stored Procedures don't make a whole lot of sense.
Wow, Julie Lerman answered!
Yes, it's possible, but not particularly easy. In particular, you must call context.Database.SqlQuery<T>() where T is the entity type you want to return, and your SQL must match up to that entity type. Otherwise, you will have to massage a result set into a type.
In general, you will have to do most of this manually, although you could probably figure out a T4 template to generate it for you, or maybe use some other tool like CodeSmith.
When is it appropriate to create a helper class for a sql server database using the asp.net framework? Basically I'm trying to create a minature wiki (with multiple pages) and storing all of the data/strings for a specific page into a table on it's own.
Always and Never.
Always, because you want good separation of your data tier from your business logic and presentation tiers (or model and view, or whatever framework you use). Make sure you're thinking of it in these terms, too.
Never, because this is already done for you, on several levels. There are numerous ORMs out there, including Linq-to-sql, NHibernate, Entity Framework, and more. More than that, what is ADO.Net but a set of classes to encapsulate your server?
Well it could be appropriate to return a single instance of a DbConnection object - that way you only specify how to connect to the DB in one spot.
You may find it useful to have a base class for your ADO layer which provides these generic methods to deal with the ADO (part of the .NET framework for connecting to SQL server).
You could have a helper method to populate an object from a DataReader using reflection too.
Also for putting parameters together to send to a SQL command or Stored procedure.
Hope you find this helpful. :)
It's heavily dependant on your project.
For code clarity, and your own sanity, you might find it easier to make a wrapper class for all of your Database manipulation. This way you can have the rest of your code work with native objects, rather than the contents of a DataReader.
Just my advice, but hopefully helpful.
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