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.
Related
I need a mechanism to detect what properties of a given View Model has changed on client. This is needed to set ONLY changed properties Modified to merge concurrent update of a same entity on the server.
I found breeze a good framework at the fist glance but I want to hear from other experienced people here.
I think the problem is not platform dependent however if you are curious I'm using Asp.net MVC 4+ and Entity Framework 6.0+
I have the main website that uses a database to store and access user accounts. I'm using EF to manage the schema. I also defined site-specific POCOs and have migrated them to the database.
Now, what if I want a separate website, for example, a resource server (Web API) that would expose (with authorization) the same data set up on the main website?
Do I create the same POCOs and derived DbContext on the resource server again? That seems like duplicating work, though.
What if I wanted to create new POCOs on the resource server and reflect them onto that same database? Wouldn't that conflict with the current migration (which is saved on the database), then subsequently mess up the EF setup on the main website?
I've seen the suggestion of putting the POCOs and DbContexts in a library and have multiple projects reference that same library. This seems viable, however I'd have to hard-code the connection string, which seems dirty to me.
I'm starting to think that EF is probably not recommended for this kind of setup. It seems like a database-first approach plays better here - though I would have to manually reedit the data contexts (most likely, LINQ-SQL) for every database schema change.
Are there any lesser-known capabilities, facts, practices, etc., for/about EF that would help in this situation?
Generally, you can avoid duplication by having one API serving both sites and have resources version for each if needed. On the other hand, if you choose reuse and add approach, creating additional EF code-first entities should not interfere with other site data layer if modeled and mapped carefully. DbContext connection string does not have to be hard-coded.
What's my options (and where) for hosting a asp.net 4.5 on a hosting service?
I want to use the built-in membership tables + to be able to create automatically a new
database using EF Code First 5
I want easy deploy
Is it good option for Code First in production? I read a lot "Development only", but it's
bother me , why to have Code First if its only for development...
Update :
My main question is even about asp.net 3/4 Code-First , what known hosting services allow you easy deploy with the enjoy of CodeFirst , meaning , auto create database and etc...
Well, your options are at the moment very limited. Firstly, as far as I know, 4.5 hasn't been released yet, so I'm not sure what hosting solutions are you actually expecting. I've heard of some testing hostings for beta version, but.. Don't know about you, but it just won't suffice for my production apps.
Secondly, code-first is meant for rapid development.
You must understand, that "code-first" is just a different way of creating your db classes in .NET. It's still Entity Framework, so if it suits you, it doesn't matter when and how you use it. Background layer is still the same as if you used "classical" auto-generated classes representing your db.
It's only depend on .NET Framework 4.0.
It's very easy to deploy.
My team is doing web development (ASP.NET, WCF), and we are at a beginning stage where everyone needs to make DB changes and use own sample data.
We use a dedicated DB server, and we want each developer to develop against separate DB.
What we appear to need is ability to configure connection string on per-developer basis in source controlled way. Obviously, we might have other configuration settings that need custom setting and finally, we'll need to maintain a set of configuration settings that are common to all developers.
Can anyone suggest a best practice here?
PS Similar issue appears when we want to deploy a built application to different environments (test, stage, production) without having to manually tweak configurations (except perhaps configuring the environment name).
You can use config transforms for your deployment to different environments. That's easy enough. Scott Hanselman did a pretty awesome video on it here.
For your individual developer db problem, there isn't any particularly elegant solution I can think of. Letting each developer have a unique configuration isn't really a "best practice" to begin with. Once everyone starts integrating their code, you could have a very ugly situation on your hands if everyone wrote their code against a unique db and configuration set. It almost guarantees that code won't perform the same way for two developers.
Here is what I would recommend, and have done in the past.
Create a basic framework for your database, on one database on your test db server.
Create a Database Project as part of your solution.
Use .Net's built in Schema Compare to write your existing database to the database project.
When someone needs to change the database, first, they should get latest on the Database project, then make their changes, and then repeat step 4 to add their changes to the project.
Using this method, it is also very easy for developers to deploy a local instance of the database that matches the "main" database, make changes, and write those changes back to the project.
OK.
Maybe not so elegant solution, but we've chosen to read connection string from a different place when the project is built using Debug configuration.
We are using registry, and it has to be maintained manually.
It requires some extra coding, but the code to read the registry is only compiled in debug (#if debug), so there is no performance hit in production.
Hope this helps as well.
Cheers
v.
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.