I am working on upgrading an ASP.Net Web Forms application to MVC + EF Web Application.
I am more or less clear about the MVC part but seems to be a bit stuck about the EF part.
Since its a upgrade so there already exists a DB with lot of stored procedures, functions and other things and I would like to keep them.
For EF Code First from DB is the prefered option as it generates the Model classes automatically.
I am struggling to conceptualize how this will actually work.
for example:
I have two tables Employee & Salary as
There is a stored procedure getEmployeeDetails which returns a cursor with properties from both tables.
I am not sure how to map this in DbContext as what I have read so far is that you can map stored procedure to a single mode and not two or more.
Can someone please suggest what can do done here and what will be the best option in terms or using EF code first with existing procedures.
Thanks!!!
Related
Before I posted this question, I did some Googling first on how a database was created through C# and mostly it points to either SMO or SQL query files and it was the time of SQL Server 2005 and 2008.
So at this day in age, is there an easier way to create a database with empty tables, tables with data in them by default, stored procedures and views?
I need a suggestion.
I think the answer is probably Entity Framework. You can do 'code first' and use database migrations, allowing you to write your C# code and use that to generate a lot of the database for you.
Ultimately though, 'easier' is subjective. I personally find EF great for the 'normal' stuff, but at the end of the day, if you need a stored procedure to do some custom logic; you need to write the custom logic, in some fashion.
Maybe have a look and see if you think it fits your needs.
https://www.asp.net/mvc/overview/getting-started/getting-started-with-ef-using-mvc/creating-an-entity-framework-data-model-for-an-asp-net-mvc-application
Looked at the database projects in studio 2013. You create a database as a series of scripts using a familiar GUI. However, changes are published - this process creates a unique change script targeting the connection you define. For new databases the whole thing gets created, but publish against a partial or out dated version and the script created in a change script to bring it up to date.
You can even writ unit tests against your database using specialist tools, although I do find them lacking a bit.
More on msdn - here
Depends. right out of gates. Sp and views. Best shot is directly from database through a workbench. I can then capture definitions and store in a file to be replayed through c#
As for tables there are many orms that can generate tables via c#. Look at entity frameworks. Code first examples
I have generated tables using EF Works fine. I then went into database and created views and sps.
The trick is to migrate new views and sps into your EF model U can google entity Frameworks code first ... Adding views and SPs.
Worst case is u create database all through database workbench. Create a script that an be played to recreate eveything. By running. Then use EF DATABASE first approach
In either case u end up with a good set of autogenerated code to manage CRUD and object management and an abstracted data model
I am new to MVC. I am going to develop MVC version of an asp.net site. The site is/will be backed by multiple MySQL databases. The data in databases is populated by an other process, which is out of my control, hence there is no chance to modify schemas any way.
My Problem is how to design entities to work with mysql stored procedures using db first approach? I am saying stored procedures, because I am not going to use all columns of targeted tables as they are, but some time I will do some calculation job at database side. Hence I am limited to use stored procedures! An other problem is designing DbContext classes for such scenario. Any help will be appreciated.
I am working on a project using entity framework code first approach, I have a situation where I need to call a stored procedure which returns multiple table, hence I want to map the result to my model. please tell me if its possible to do it and if yes then how can i do it.
Code First currently only supports mapping to tables. This unfortunately means
that you can’t map Code First directly to stored procedures, views, or other database
objects. If you are letting Code First generate a database, there is no way to
create these artifacts in the database, other than manually adding them once Code
First has created the database. If you are mapping to an existing database, there
are some techniques you can use to get data from non-table database artifacts.
i am also facing the same problem and not able to get any solution, so i called stored procedure using ExecuteReader and then mapped it to models using autoMapper.
Let me know if you are looking for code
I am working on a MVC4 project which will need to use a number of different databases, each with a few stored procedures for searching. The site is an asset search tool which needs to query various existing systems. If I allow the EF to generate models on its own, I will end up with a Model for each procedure I use in each database.
What I would prefer is to have my own POCO model already defined and the EF maps its results to that Model. So regardless of what database the data is taken from it maps back to that same Model. The column names in each database differ slightly so it would really need to be mapping columns to model properties.
There is no writing back to the database, it purely selects data out.
On the 'Edit Function Import' form I can create a model based on the results. There is also an option to view 'Function Import Mapping' but it does not appear to do what I am looking for.
Has anyone else tried this?
Added an image to help explain the issue
The closest to this I have managed so far is to have EDMX1 query 2 databases. This only works because they are on the same Db server. I had to fully qualify the Db names in the stored procedure. I could then use 1 EF Model as a return type for the 2 queries. That Model still is not usable in another EDMX though, so if I need to connect to a different Db server, I still cannot share the Model. So the problem is not solved.
Here is image of current progress.
Function Import Mapping is for mapping stored procedure / function calls to EF code. It's not really relevant here, unless you're using stored procs (which is not the way to go 90% of the time with EF - only use stored procs for more complex procedures).
An EF context, by its very nature, can only have a single database associated with it. You need to create multiple contexts in order to access multiple databases at once.
What I would do in your case is create a database-first schema (.edmx) file for each database, then write a service layer abstraction above it that allows you to flatten the data into your expected model. This is the kind of thing I do all the time, regardless of how many databases I'm working on at once. You've almost outlined this in your first diagram. The service layer may have multiple classes (for example, for a blog website you might have BlogService, UserService, CommentService etc), each of which contain methods that you call from you application layer.
I've put a quick diagram together that might help to explain
http://www.gliffy.com/go/publish/image/4818386/L.png
The service layer does all of your EF work, and your application layer (or business layer, whatever you want to call it) will do all of your business logic.
This setup lends itself well to TDD and Dependency Injection / IoC. Everything is neat and nicely separated.
I have a Stored Procedure that returns a dynamic result set based on a temporary table. My project uses LINQ for Data Access, but I can't incorporate LINQ with this Stored Procedure because it has a dynamic "shape" (I can't say before hand which columns will come back or how many there will be), so LINQ can't generate at design time an object that can hold the results.
I am trying to integrate the stored procedure the old fashioned was, using SQLDataAdapter and such, but I was hoping that I could still tie into LINQ so that I don't need to manage a separate transaction mechanism as that would be a disaster.
Is this possible? Thanks.
One best practice is that a stored procedure should never be coded such that it gives different columns in a result set based on inputs.
It sounds like your design is causing the single stored proc to try and do too many things. I'd highly suggest you change this.
First - you aren't using "LINQ" for data access. My guess is you are using Entity Framework for data access. If you are, it depends on which version of EF you are using.
New in Entity Framework 4 is shaping data from a stored proc. For step-by-step instructions, see this blog post: http://blogs.msdn.com/b/nihitk/archive/2010/04/23/ado-net-entity-designer-in-vs-2010-stored-procedure-return-type-shape-sensing.aspx
If you are using Entity Framework 1, which comes with .NET 3.5, then no EF does not have the ability to sense the shape of the stored proc data.