I've created a business layer with a database model to be used in an ASP.NET application. I've used Linq To SQL Classes in Windows Forms before but using ORMs in per-request web applications is foreign to me. I've a few things I couldn't figure out and I'd appreciate if anyone give me any insight..
My BLL has static methods like GetRecord() or UpdateRecord(). Each one of these methods creates a new ObjectContext instance, destroyed after unit of work. I don't have any HttpContext.Current.Items cache implementation.
I'm using EF .NET 3.5.
I've created a pre-generated view (Model.View.cs) and added it to my solution. Is this all I have to do to use it? Also do I need to publish csdl, msl and ssdl files with my dll?
Is precompiling queries bad for ASP.NET applications? I have like only one or two queries for any ASPX page and very rarely a select query used twice in the same page. Will it slow down the application if precompile my queries? I wonder if a precompile made by Session A would be useful for Session B?
I've created the following method to update a record in ASP.NET page and I wonder if it is a good way to do it:
ASP.NET gets the record(Entity) using BLL.GetRecord()
Updates any values
Sends updated record to BLL.Update()
BLL.Update() checks if the record exists
Uses context.ApplyPropertyChanges() to update the record
I've red a few entity framework performance charts and in every one of those charts there are two different statistics for queries: first run and the second run. Since I work with unit-of-work type of design, will my queries never see second runs?
Thanks.
You need the CSDL, etc., either as files or resources. View pre-generation helps with performances, but doesn't relieve you of the need to include EDMX in some form.
No.
OK as far as it goes. Hard to say more without seeing code.
It depends. This post should help.
Related
I am wondering some point on deploying an Asp.NET MVC5 application to my own server.
What if it happens, if i add more attributes in one of my model class or add more model class. What should i do for not losing data.
Is there any other options shoul i need to perform other than asp.net mvc4 since i could not find any tutorial about deployin asp.net mvc5 with Identity.
What is the best efficient way to change my application view, controller and model on run-time. Can i working on my local PC while using the remote code file and database ?
Regards.
I have a hard time understanding your requirements but for the database part, I would recommend "entity framework migrations". It's made handling model changes locally and remotely.
http://msdn.microsoft.com/en-us/data/jj554735.aspx
I have worked with entity framework migrations a lot but sometimes if you make big changes, such as Foreign keys or enums, the migrations give a problem. I then started to use a tool from RedGate.com called "Sql Compare." Works better than Entity migrations - now I don't worry about data changes. Usually this will not lose data, but if it is going to lose data, it will warn you.
Best solution to losing data -make backups.
Using Entity I currently have dbcontext that has every table in it.
I'm wondering if that's what everyone does, or do you have a context per module for example. To me the dbcontext was a connection to map the models to a database, and since there is only one database, I only need one.
Before I get too far along I want to see if that's appropriate.
So 1 db context per database or many?
I went through this same process recently and found some great resources on the subject. Here are a couple that were very helpful:
Shrink EF Models with DDD Bound Contexts.
How to decide on a lifetime for your ObjectContext.
I was building a Desktop app, and I ended up using multiple contexts so that I could keep the lifetime tied to the module rather than the application. This has worked out very well for me, and I like that my DbContext isn't swamped with DbSets and is limited to the ones that are relevant for the current module.
In an ASP.NET MVC app, it is different since the DbContext will only live as long as the request, and in those cases, I usually use a single DbContext to simplify things unless the database is very large. With a large database, I would probably break it apart into multiple DbContexts just to limit the overhead and the clutter, and keep things compartmentalized.
currently the EF hasnt been made to be broken down into diff dbContexts. Here a great talk about it
What we have done for this case that we have made a project diff from our MVC website just for the database generation and then have separate dbContexts for every requirement.
This way our dbContexts are never large and are easy to maintain
I have just started working on entity framework in an ASP.net application and I was wondering if someone could point in the right direction with respect to best practices. I have some questions in particular which I have listed below.
First of all I am using entity framework 4.0. I already have my database created and so I created a class library and generated the entity model from the database. I had been using Guids generated by the database so I had to modify the ssl to include the attribute StoreGeneratedPattern="Identity". Is there a way to do this automatically or do I have to manually edit the ssl everytime I update the database and the model? (For those of you know are facing a problem with guids or want to know why I am doing this.. this is a clear article on the problem with auto generated GUIDs)
I was planning on using a single file in the class library to hold all the database queries. Is this good practice? How would I ensure different programmers dont rewrite the same queries over and over?
I was planning on using a unique context per method. Is this the right way to go? I read through Rick Strahl's post on context lifetime management. But I am still not sure if a unique context per method is the right way to go.
Can I have my database queries as static methods since they do not make use of any instance variables?
If I use a unique context per method as mentioned in 3 and I wish to modify an entity object returned by one context what would be the best practice? Do I use the attach functionality to attach the object to a new context and save the changes ? I havent tried this but I have read a couple of articles and it seems a bit straightforward but wanted to know if there are any alternatives to this.
If you any suggestions on how you use Entity Framework in an ASP.net application I definitely could use help. This is my first ASP.net/Entity framework application so any tips will help
This was issue in initial version of VS 2010. In some cases this should already work correctly once you have VS 2010 SP1 installed. If it doesn't install this KB.
You can easily get huge class with a lot of static methods. Try to use some separation by the entity type you are querying. You will never fully ensure that another programmer will not create the same query again. This is about correct query naming following same naming policy, documentation and communication among programmers.
Unique context "per method" is usually not needed. In most cases you should be happy with unique context per logical (business) transaction - in case of web application logical operation is in most cases single request processing = one context per request.
If you pass context instance to your queries the answer is yes. Once you don't create them as static and they will take context instance from their class instance you will be very close to repository pattern.
This is exactly problem with context per method and it is hard to solve because to make this work you must first detach entity from the first context and attach it to the second context. If your entity has also related entities loaded all these relations will be nulled during detaching (unless you use deep clone instead of detaching = creating second instance of the entity).
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 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.