I want to start using Dapper because I think it's easier to use with Stored procedures than to map every stored procedure with Entity Framework to replace CRUD operations in general.
I would like to know how can I create the POCO classes with dapper, and if it is not possible, could I create the model from the Database using Entity framework and then use the classes created with dapper?
Thanks!
There are a number of projects where I have used dapper alongside Entity Framework / nHibernate.
There is a distinction between the POCO classes created for Dapper and the domain entities used by code first Entity Framework and you should create both.
Stored procedures will work with a shaped view of the data and do not have the responsibility of representing the entire domain.
Following single responsiblity practises the POCO classes you use should only contain those properties used by the stored procedures to are interfacing with.
If you are not using Entity Framework for data access and want to replace it completely with Dapper and stored procedures then you are failing to realise any of the benefits of an ORM and should simply hand craft the schema and the POCO classes it uses.
You can generate POCOS from a schema and tools exist to do this, given the overhead of creating your own classes which can be better tailored to the application layer I woudl suggest there would be no benefit.
Related
How reusable are the results of using EF?
Currently, I use stored procedures for 100% of my data access. The main reason I may be looking to do things differently for my newest project is for maintainability: adding an attribute to a table means manually altering dozens of stored procedures. If I understand EF correctly, I should be able to add an attribute to an Entity in my EF model, and then ask EF to update my CRUD methods for me. awesome.
However, there is one thing holding me back: reusability. I like that I can make the SP's for a given database once, and be done with them; I can make 12 applications that all use that database and getting that data will be as easy as calling the correct SP.
Will the same be true if I switch to a more EF-centric approach?
Can I import an Existing EF Data Model and have it work without too much trouble?
Can I make it so that I alter the Data Model once, and that change is felt across all applications?
Ad1. You can easily reuse complex EF queries if you follow the Repository pattern. Repositories are where you encapsulate your data access and, yes, repositories are easily reused between different modules/applications.
(not that you can't reuse code without Repositories! Repositories are just a common way of doing it for data access layer)
Ad2. I am not sure what you mean by "import existing EF model" (import where?) but usually EF models are straightforward and can be reused
Ad3. Just have your model in a separate assembly.
A real benefit to using EF is getting away from stored procedures.
The problem that exists with using stored procedures for all your data access is that you are forced to put business logic into your data layer.
Check out Should the data access layer contain business logic? While its not true in every case, generally keeping your business logic in your business layer gives you better separation of concerns.
I have an EF project that I use as the data layer for several applications. This allows me to change it once and have all the other projects get the benefits. Granted, sometimes supporting code needs to be changed in these other projects, but you'd have that same problem in a stored procedure model as well.
Any N-tier design would solve this problem by simply creating a class (in a class library) that understands how to access the data by using entity framework. Then any applications that want to access the data uses the class library, configure a connection string in the app.config or web.config and you're done.
Before entity Framework, Developer was writing the code Entity Classes which is contains the getter & Setters Method for Data Table Fields (Columns).
what is the purpose of introduce Entity Framework, and what's different between Entity Framework and Older traditional way to write down Entity Classes?
If you do not use EF (or any other ORM tool), you will have to write both entity classes and related database operations by hand.
ORM tools creates both entity classes and an abstraction of related DB operations automatically.
In case of EF, it creates entity classes and an ObjectContext (or a DBContext) which allows you to manipulate DB entities without writing SQL code.
Entity Framework provides ORM capabilites to Entity Classes. You don't need to craft CRUD or Database operations on database layer, EntityFramework handles it.
I got confused on what are the differences between Linq-to-SQL and Entity Framework when following the database first approach as I can not find any clear differences.
In my case when I was using Linq-to-SQL I used to create the tables then I use Linq-to-SQL to create the classes that represents the tables, and now when I switch to Entity Framework I am still following the same steps (creating the database tables then create the associated classes using EF).
And I am interacting with these classes on the same way, for example I used to query the User class using the same syntax and approach but one time when the User class was created using Linq-to-SQL and the other time when it was created using EF, so where is the difference ?
public IQueryable<User> findstudents(string term)
{
return from student in entities1.Users
where student.UserID.Contains(term)
select student;
}
Second question if I use EF to map the tables into classes, is it still possible to use Linq-to-SQL in the same application to query the EF classes?
LINQ is a base technology - that's the syntax that gives you the SQLish query options in C# - that's totally independent of whether you use Linq-to-SQL or EF. So if you want to query your data classes using the LINQ syntax - you can do that with both frameworks - but once you use Linq-to-SQL and once you use Linq-to-Entities. You cannot use Linq-to-SQL against an Entity Framework EDMX model.
Linq-to-SQL is great
if you need very simple 1:1 mapping - one table equals one class in your domain model
if you never need anything else but SQL Server (Linq-to-SQL doesn't support anything else)
if you want to be up and running really quickly
Entity Framework on the other hand
supports multiple backends (SQL Server, Oracle, Firebird - other will likely follow)
supports a full conceptual data modelling strategy - you define the physical model in the database, the conceptual model in your app, and the mapping between the two
gives you the ability to handle things like mapping a single business entity to several tables
support table-per-hierarchy and table-per-class inheritance scenarios
support refreshing/updating your model (EDMX file) from the database when things change (in Linq-to-SQL, you basically have to drop + recreate those entities involved - thus loosing all your customizations you might have made)
In brief: Linq-to-SQL is a great, simple and lean'n'mean ORM for SQL Server - use it, if it does all you need. Entity Framework is quite a different beast, much more capable, but also more complex, much bigger - perfect for your next enterprise-critical app, but probably overkill for your personal blog app :-)
If you want to create something that's "future-proof" and will use the OR technology that Microsoft is pushing into the future, then you should go with Entity Framework. Especially in v4, it's also a lot easier to use, a lot more slimmed down and more useful than ever before.
They both seem to create classes based on a database schema. Why would you use the entity framework model over a table adapter?
They both allow me to easily drag a sql table onto a surface in Visual Studio, after which a class and all the code is generated which allows me to automatically create/update/delete records.
I know the entity framework is the clear choice, I just don't understand why.
Thanks!
Data-Set, Data-table and Data-row offers relational API - they are your RDBMS entities mapped as objects in .NET world. You can't have inheritance. You cannot have graph like structures.
EF on the other hand, allows you to model your objects as you want them to and then map that to RDBMS schema so that it would manage the persistence part. With EF, you can work with the conceptual (domain) model rather than relational model. For example, a EF entity might be projection from multiple tables or you can have several entities built upon a single table (e.g. inheritance scenario).
I have a question about inheritance in Entity Framework 4. We are using a database-first approach and would like to restructure our model to use inheritance. Here is a white board mock up of the hierarchy we would like to use in our model.
Image 1
In case those scribbles are not very readable, it's something like this.
USER <- PROVIDER
USER <- VENDOR
PROVIDER <- EMPLOYEE
So USER is the base class for providers and vendors. And employee then inherits from provider.
I found a couple great articles describing Table-Per-Hierarchy inheritance and Table-Per-Type inheritance.
They seem simple enough but both ways require an entity to be mapped to a table or tables. What if you have an entity that is mapped entirely to stored procedures?
Image 2
Is it still possible to do inheritance in EF even if an entity is mapped to stored procedures? How would that look? What kinds of stored procedures would we need to have to accomplish this?
If it's possible we really just need pointed in the right direction.
I have searched and searched and finally arrived at the conclusion that it is not possible to do inheritance with entities that are mapped to stored procedures. So unless someone can prove otherwise, I'm marking this as the answer.
I am using a completely stored procedure mapped repository architecture in my MVC project. In that we are not using the entity framework, instead of that we use Microsoft Enterprise Library. We are using the methods from it. From my experience, The repository contains only methods for data manipulation using stored procedures. The Tables are mapped to Models. There are ViewModels which are custom Model classes for handling properties which are defined as custom in the project. There is one service layer to separate the Controllers and Repositories. So I think you can adopt the method of repository mapped entirely to stored procedures