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
Related
Can you please spend ur time 4 this and help me as it is a big project if we do mistakes noe we will repeat the same mistake in next 3 years.
we are starting a new big project in asp.net mvc4, Html5 and CSS3 (We preffer these Because our application should target tablet, desktop, mobile).
So I feel bec its new we can better start with code first approach(latest) like first creating classes and prepare db(sql express) and deploy well and also we have support of EF migrations, So I think that way the proj become more successful and maintainable easily.
But the small concern with the manager, I dont know whether he is correct or iam wrong bec he has good experience in working but he is also new to MVC. below is my query ive explained pls look into this,
-Database with tables are ready.
-Now we have to start the project. (I think we can do code first reverse engineering and start)
But, For that our manager asked our team to prefer and write stored procedures, and use asp.net mvc 4?
My question is, is it the right way to do the project with that combination? Why am asking you is I have been watching videos/tutorials through online they never said the samples with that combination and all are saying with out using stored procedures, is it any problem like performance we will not get as we are using storedprocedures through EF OR because we are using stored procedures in backend we will get performance and maintaing easily as our PM says,
Iam totally confused???? please help me in this if you have solution.
There is no any issue using stored procedure in MVC, you can go for it. There would be worth reading this about your performance question.
If controller is not depended on the implementation of data access layer then no matter what you use whether EF or Stored procedure, you are good to go.
Darin Dimitrov already explain it about here.
That videos doesn't represend examples of using stored procedures, because they doesn't need stored procedures! All of results from SPs can be achived by EF easily and with much less effort and waisting times.
However, you should consider 3 things:
1) It seems that you all are new to EF. So, using EF is a potentially thechnical risk for your project!
2) Keep in mind that EF will cause some overhead to your app and if you're creating an app which works with huge data or should handle many requests at once, maybe it's better for you to keep going through SPs.
3) From the other hand, if you get familar with EF, it will dramatically progress your project fast and easy because of its useful abstractions and conventions.
So, first know your project, then deside which way you should go...
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.
I've just finished going through the MvcMusicStore tutorial found here. It's an excellent tutorial with working source code. One of my favorite MVC v2 tutorials so far.
That tutorial is my first introduction to using ADO.NET Entity Framework and I must admit that most of it was really quick and straight-forward. However, I am worried about maintainability. How customizable is this framework when the customer requests additional features to their site that require new fields, tables and relationships?
I am very concerned about not being able to efficiently execute customer's change orders because the Entity models are basically drag-and-drop, computer generated code. My experience with code generators is not good. What if something goes haywire in the guts of the model and I'm unable to put humpty-dumpty back together?
In the long run, I wonder if using hand typed models which human-beings can read and edit is a more efficient course than using Entity Framework.
Has anyone worked enough with entity framework to say that they are comfortable using it in a very fluid development environment?
I have been using entity framework(V1.0) for about a year in my current project. We have 100s of tables,all added to the edmx.
Problems we face (though not sure if the new entity framework resolves these issues)
When you are used to VS.net IDE, you
will be used to doing all drag/drop
operations from your IDE. The
problem is, once your edmx hosts
100s of tables,the IDE really stalls
and you would have to wait for 3-4
minutes before it becomes responsive
With so many tables ,any edits you
do on the edmx take long.
When you are going to use a version
control, comparing 10000 line XML is
quite painful. Think about merging 2
branches each having a 10000 line
edmx,the tables, new association
between tables, deleted associations
and going back and forth comparing
xmls. You would need a good xml
comparison tool if you are serious
about merging 2 big edmx files
For performance reasons we had to
make the csdl,msl and ssdl as
embedded resources
Your edmx should have to be in sync
with your DB all the time,or at
least, when you try to update the
edmx, it will try to sync and might
throw some obscure errors if they
are out of sync.
Be aware that your
entities(tables/views) should always
have a primary key, else you will
get obscure errors. See my other
question here
Things We did/I might consider in the future when using EF
Use multiple edmx by using 1 edmx
for tables logically grouped/linked
together. Be aware of the fact that
if you do this, each edmx should
live in its own namespace. If you
try to add 2 related tables(say
person & address) to 2 edmx in the
same namespace, you will get a
compiler error stating that the
foreign key relationship is already
defined. (Tip: create a folder and
create the edmx under this folder.
If you try to alter the namespace in
the edmx without having the folder,
it does not save properly the
namespace the next time you
open/edit it)
fewer tables in edmx => less heavy
container => good
fewer tables in edmx=> easier to
merge when merging 2 branches
Be aware of the fact that object
context is not thread safe
Your repository (or what ever DAO you use) should be responsible for creating and disposing the container it creates. Using DI frameworks, especially in a web app complicated things for us. Web requests are served from the threadpool and the container were not disposed properly after the web request was served as the thread itself was not disposed. The container got reused (when the thread was reused) and created a lot of concurrency issues
Don't trust your VS IDE. Get a good
XML editor and know how to edit the
edmx file (though you don't need to
edit the designer). Get your hands dirty
ALWAYS ALWAYS ALWAYS (just cannot emphasize this enough) run a
SQL profiler (and I mean each and
every step of your code) when you
execute your queries. As complex as
the query might look, you will be
surprised to find how many times you
hit the DB Example:(sorry, unable to
get code to the right format,can
someone format it ?)
var myOrders = from t in context.Table where t.CustomerID=123
select t; //above query not yet
executed
if(myOrders.Count>0)//DB query to
find count {
var firstOrder = myOrders.First()//DB query to get
first result
}
Better approach
// query materialized, just 1 hit to
DB as we are using ToList() var
myOrders = (from t in Context.tables
where t.customerID=123 select
t).ToList();
if(myOrders.Count>0)//no DB hit
{
//do something
var myOrder = myOrders[0];//no DB hit
}
Know when to use tracking and no
tracking(for read-only) and web apps
do a lot of reads than writes. Set
them properly when you initialize
your container
Did I forget compiled queries ? Look
here for more goodies
When getting 1000s of rows back from
your DB, make sure you use IQueryable and detach the
objectContext so that you don't
run out of memory
Update:
Julie Lerman address the same problem with a similar solution. Her post also points to Ward's work on dealing with huge number of tables
I'm not too familiar with Entity Framework, but I believe it simply generates an EDM file which can be hand-edited. I know I've done this quite frequently with the Linq-to-SQL DBML files that the designer generates (it's often faster to hand-edit them than use the designer for small tweaks).
You know I'd be interested if any developers can provide some insight into this.
Any Entity Framework examples seem to only consist of about ten to twenty tables, which is small scale really.
What about using the EF on a database with hundreds or even a thousand tables?
Personally, I know several developers and organisations that were burned by LINQ-to-SQL and are holding off for a year or so to see what direction EF takes.
Starting from Entity Framework 4 (with Visual Studio 2010), the generated code is outputted from T4 (Text Template Transformation Toolkit) files which you can edit so you have full control over what is generated. See Oleg Sych's blog which is a mine of information about T4. Code generation is not a problem and T4 opens so many perspectives that I can't live without anymore.
I'm currently working on a project where we use Entity Framework 4 for the data access layer, and Scrum as the agile project management method. From one sprint to another, there are several tables added, other modified, new requirements added. When you have run once into each potential EF problem (like knowing that default values from database are not persisted by default in the .edmx file, or changing a nullable column to a non-nullable and updating the designer doesn't change the mapped property state), you're good to go.
Edit: to answer your question, it's EF 4 whose code generation is based on T4 rather than T4 supporting EF. On EF 3.5 (or EF 1.0 if you prefer), you could in theory use T4 by writing them from scratch, parsing the EDMX file in the T4 code and generate your entities. It would be quite a lot of work considering all of this is already done by EF 4. Plus, Entity Framework 3.5 only supports one type of entitiy, whereas EF 4 as built in or downloadable templates for POCO entities (that don't know anything about persistence), Self-Tracking Entities...
Considering Entity Framework itself, I think it was lacking many features in its first release, and while usable, was quite frustrating to use. EF4 is much more improved. It still lacks some basic features (like enum support), but it has become my data access layer of choice now.
I've been looking into ASP.NET Dynamic Data and how it does scaffolding and routing. I've only scratched the surface, but it's looking like I'd have to create a template for each table that I didn't want to display all columns the same way.
My first impression after looking at dynamic data is that it would seem like less time on the programmer to have to edit one-time generated user controls rather than build a template for each table that doesn't have a uniform display behavior.
What proven solutions are people currently using that help ease the laborious tasks of creating ASP.NET CRUD type user controls?
Thanks
In ASP.NET webforms we use CodeSmith. From a single entity we generate admin pages, codebehinds, service layers, data layers and db stored procedures. All in a matter of seconds. I'd recommend you check it our for quickly building the crud in your apps.
We're actually working on our own code generation tool. It has already proven to work perfectly on the lower layers and now we're on the way to extend it for the presentation layer, that is for generating user controls.
I've not looked into dynamic data (although I'd like to when I have some time) but my biggest fear is always to lose flexibility. The problem is that these front-ends are then maybe generated dynamically each time based on some template and editing, especially bringing in special customer wishes becomes quite difficult. For small standard apps it may work perfectly though.
What we're therefore doing is to "generate" these usercontrols based on a set of standard custom server controls we've developed, but we'll generate just the first time from some static information about the entities in our application. Then you can continue customizing.
Such systems should help the developer, improving his development speed, doing the initial awkward work but then they should give him the flexibility to modify till the maximum. They should not add additional complexity...
I used .netTiers CodeSmith templates long time ago (years) and it was proven so strong, so, it must be more than great now.
I know a (big) company who have built a customization engine (allowing GUI for internal company options) around those templates to use them in most of their applications and were so successful.
I've used http://www.ironspeed.com/ in the past which has been great. Saved us MONTHS of time on our last project which has a big DB, so the cost is worth it. But it looks a bit ugly and can be tricky to update the DB schema once you've generated.
Obviously not much widespread use out there other than whats provided in Visual Studio.
Have a look at Blinq.
I've received a project for internal use. My application has to store about 100 rows of meta data of a game and each row has about 15 fields maximum. Fields can be game name, game category, maker, source code path, etc. I will most likely have to join about 5-10 tables for each row of record. Only a few people are using it and will receive very little hits. Speed performance is not a much of an issue. The rows of data I have to present must be sortable and searchable
My current solution is to use ASP.NET's GridView control with ASP.NET's AJAX UpdatePanel to give it that ajax feel. I'm thinking of using LINQ-to-SQL as my data access layer. I'm thinking of building my own custom search engine but if there's an existing control that has this feature already, i would prefer to use that; anyone know of such control exist? Anyways what do you guys think?
Update #1:
I'm looking into creating a DynamicData website. Any have thoughts on that?
Use ext.js!
Look at the Grid Samples, its a very shallow learning curve and provides you with amazing results in little to no time.
http://extjs.com/products/extjs/
Basically, you expose your data via a web service (asmx or WCF, your choice), throw the Ext.Js grid onto your html/aspx page and point it at your webservice. Configure the control for things like sorting/searching/expanding/grouping/paging etc (use the api reference http://extjs.com/deploy/dev/docs/).
ASP.NET Dynamic Data looks really cool, particularly for sites where you've got:
lots of data
not a lot of worries about performance
no / little desire to skin / design the site
no / little desire to extend existing / write new functionality.
So I'd say that's a good match for your project.
Gridview is your best bet. It's so powerful if you know how to use it correctly. It does automatic sorting and if you can code pretty well you can get the data to be filterable(if that's a word). It also makes the Connection to the database for you....so in my opinion, you can't beat the gridview when it comes to reports like that.