I had a conceptual question about EF.
I am pretty new to the idea of an ORM in general, so I wanted to get some clarification on somethings:
I have an existing database, and I want to convert the data I am pulling from that data into objects that my application can interact with as objects, rather than just data.
An ORM will accomplish that, correct?
In EF can I create methods specific to my objects? For instance, can I make it so my application can call something like employee.ViewDetails() Where employee is an object?
If so, is there a simple tutorial you could recommend?
Is EF portable between applications? Meaning, is it easy to build an EF structure and then port it to multiple applications?
I can just do that by referencing it from different solutions, no?
Thanks for all the help
Before Answering your Question let me give you short brief about Entity Framework
Using the Entity Framework to write data-oriented applications provides the following benefits:
Reduced development time: the framework provides the core data access capabilities so developers can concentrate on application logic.
Developers can work in terms of a more application-centric object model, including types with inheritance, complex members, and relationships. In .NET Framework 4, the Entity Framework also supports Persistence Ignorance through Plain Old CLR Objects (POCO) entities.
Applications are freed from hard-coded dependencies on a particular data engine or storage schema by supporting a conceptual model that is independent of the physical/storage model.
Mappings between the object model and the storage-specific schema can change without changing the application code.
Language-Integrated Query support (called LINQ to Entities) provides IntelliSense and compile-time syntax validation for writing queries against a conceptual model.
Going Back to your first Question
Yes
Entity framework is useful in three scenarios.
1- First, if you already have existing database or you want to design your database ahead of other parts of the application. (Which is your current case)
2- Second, you want to focus on your domain classes and then create the database from your domain classes.
3- Third, you want to design your database schema on the visual designer and then create the database and classes.
2) in EF can I create methods specific to my objects? For instance, can I make it so my application can call something like employee.ViewDetails() where an employee is an object? If so, is there a simple tutorial you could recommend?
Yes Sure Take a look on this:
- https://msdn.microsoft.com/en-us/library/dd456847.aspx
- http://www.asp.net/mvc/overview/older-versions-1/models-data/creating-model-classes-with-the-entity-framework-cs
3) Is EF portable between applications? Meaning, is it easy to build an EF structure and then port it to multiple applications? I can just do that by referencing it from different solutions?
you might need to Implementing the Repository Patterns
Have a look at this Amazing tutorial
http://blog.gauffin.org/2013/01/repository-pattern-done-right/
http://rycole.com/2014/01/25/entity-framework-repository-pattern.html
Hope this helps!
Wish you the best :)
Blubberbo,
There are various ways to work with EF, they are Code First, Model First and Database first.
More information can be found in the below SO post.
Code-first vs Model/Database-first
1) You can use LINQ to SQL or LINQ Objects in context with an ORM like EF to interact with Objects.
2) If you would like methods specific to specific types, then you might want to take a look at writing extension methods for specific types.
More information here
https://msdn.microsoft.com/en-us/library/bb311042.aspx
3) To make it portable, you might want to build abstractions around it, like for example you might want to write repository classes to separate the DB layer that uses EF and the layer that calls it(a.k.a the repository layer).
More info can be found here
http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application
Hope that helps,
Praveen Raju
Related
Our team has just started using Sql Metal and I have been playing around with it for 2 days. While doing this, I have noticed couple of things.
When we run command like following
sqlmetal /code:ps.cs /server:devapp042dbs
/database:promotionalsponsorship /namespace:DAL
It creates a "LINQ to SQL SQLMEtal" object model. Now, this is not our regular class. It has a lot of autogenerated code and it almost smells like LINQ/EF with a lot of autogenerated properties and methods.
I have used Micro ORMs like Dapper and ORMLite from Service stack and the onderful thing about those is that it works with the simple objectmodel that we have created rather than auto-generating its own object model.
My question is that can we use these SQLMetal mapping classes as our Models of the application or we have to create a simple wrapper class around it using which we can extract all the information that we need to.
To clarify my point following are the samples of what I call a SQL Metal Class and a simple model class
Although this question would possibly be closed, as the answer is subjective, the short answer is yes, it is perfectly valid to use such autogenerated set of classes as your model. There are plenty of succesful apps built this way.
Since these classes are partial, you can even extend your domain model by adding custom properties/methods/events.
If you are concerned that the autogenerated code is not clean enough, consider the code first approach of the Entity Framework, nHibernate or any other ORM that supports this scenario. This way you start from a clean POCO model and just define its mapping to a relational structure.
This question already has an answer here:
ORM Entities vs. Domain Entities under Entity Framework 6.0
(1 answer)
Closed 7 years ago.
I start using Entity Framework about a year ago using Database-First approach. While reading and doing research online, I came across some terminologies that are confusing me. I was wondering if someone can help clear up some questions I have:
1) Using Database-First approach, I build my SQL Tables and create my edmx file from the database. From there, I start coding by create a Data Context and then accessing the entities. I recently read and see that I can right click in the .edmx file and "Add Code Generation Item" and then add "Ado.Net EntityObject Generator/EF 5.x DBContext Generator/EF4.x POCO Entity and etc. What is the purpose of these different code Generators? Am I suppose to implement them? When should I implement them?
2) I'm reading a lot about "object model and domain model". Is EF an object model or domain model ORM?
Thank you in advance for any information.
Add Code Generation Item
By default classes are generated with the help of EntityModelCodeGenerator. With the help of custom code generation, you can customize this. Why you would want to do ?
One example I could give from top of my head is - if you want to implement INotifyPropertyChanged interface by every single entity generated by EDMX. By default EntityModelCodeGenerator would not do that for you. Thus, you would want to customize this.
(Please note this is just my theoretical knowledge however the above example is quite a practical situation)
Domain Model vs Object Model.
Regardless the difference one thing for sure is Domain Model is Object Model too because in both cases you are defining classes, and association. This is how I define Domain Model and Object Model.
The only major difference could be how you are defining objects; in case of Domain Model, you are completely thinking from Business point of view and defining your objects.
From what I see that it is probably EF Database first is Object Model because when I am doing Database designing I am less thinking about Business, rather I am thinking about what is to be stored.
If am making POCO then I probably will be thinking from Domain Model point of view.
In case of EF - Code First, I have started thinking from Business point of view and make my association, then after I think of how objects will be stored.
So it is just a perception and at the end whether Domain Model or Object Model, ORM i.e. EF will provide you to persist this object into the database.
I hope it helps.
You don't normally need to use the "Code Generation Item" option. It is used to perform changes in the version of EF being used, and you could use it to do some custom code generation. In general, you should be able to leave this option alone.
EF is really an ORM (Obect-Relational Mapper). It takes objects and maps them to relations (tables). It can be used as either an object model or domain model (or both) as well depending on how you define those terms.
Can you recommend a DAL object creator that is simple yet useful. I want something that creates and updates object the way LINQ does. It should be in c# and much better if it splits object's properties and data access methods in partial classes.
We've used CSLA before but I want something more simplier for our next project.
Thanks in advance
Just a humble recommendation as there are plenty of great products out there - we have been using EntitySpaces (an ORM) for a couple of years at our shop and like it.
If you are looking for an ORM, see here:
NHibernate, Entity Framework, active records or linq2sql
Are you just looking to use raw ADO.NET and also maybe datasets? If so, do you want a code generator to generate your data layer for you without a full blown ORM?
If you want to use Linq (not Linq-To-Sql), then you need an ORM at this point.
CSLA is not really an ORM and doesn't really do much from a data layer perspective. It is more of a business layer tool.
I am designing an application where I want to reduce the burden on the developers for future for development. In this I have list of classes e.g-"User,Account,Permission and etc" now these classes are associated to the table in the database with the name of the class same as data table. I want my business layer to be robust so that in future whenever I add any more column to the data table I don't have to rewrite insert update and delete command just adding property to the class should do the job.
Any Idea how to do this?
What you are looking for is probably an ORM (Object-Relational Mapping) framework. The most popular ones for .NET includes Linq-to-SQL (or Entity Framework), NHibernate nad ActiveRecord. Using an ORM is considered a best practice for achieving a maintainable and robust Data Access Layer.
See a list of frameworks here.
What you're probably looking for is to implement an Object Relational Mapping (ORM) solution. Many ORM solutions help you maintain table and entity definitions and also create the appropriate queries for you.
Popular ORMs for the .Net Framework include NHibernate, the ADO Entity Framework and LINQ to SQL. Otherwise you could consider mapping your data model using templates (like using Codesmith, or the Net Tiers templates).
You could check out the answers to this question for more advice on picking an ORM solution, or you can just browse some ORM related questions tagged here.
I think what you are looking for is a Data Transfer Object. Here's an article that explains more about the DTO pattern.
Additionally, here's an article that explains how to implement a DTO with a Dataset. In your case, the Dataset would be replaced with your own Datalayer.
Picking an ORM solution is one way, additionally i would mention the upcoming Oslo.
For a more "traditional" approach i would take a look of Data Abstract.
Quite interesting reading about this topic is the Persitence Patterns article. It explains the most common and basic design patterns used for the Data Access. Also it discusses when the concrete DP might be more suitable than the other.
Came across this:
http://www.eggheadcafe.com/articles/adonet_source_code_generator.asp
And wondering if this is the right solution as I am not that big of a fan of creating a class for every stored procedure or do I use Enterprise Library for ASP.net 2.0 project.
You definitely shouldn't be creating a class for every stored procedure. There are a number of approaches you can take to handling your database interactions. You should have a good look at the major frameworks out there and decide which one best suits you. The Castle Project solution is great, and relies on nHibernate (nHibernate). LINQ is a similar offering by Mircrosoft (LINQ Project). Both of these solutions are full ORM frameworks (Object Relational Mapping) and will generate dynamic SQL to persist your objects in the database. Each also has it's own quirks and likes you to structure your objects in particular ways. If you don't want to manage the SQL your system uses, I would definitely recommend one of these approaches.
I come from a database background, and prefer a bit more control over my SQL. In particular I like to have my interractions handled by stored procedures. I find this enables me to control both the SQL better for optimisation, but helps me manage database security in a more friendly manner. To accommodate this approach, I recommend something like iBatis (iBatis). iBatis isn't a full ORM, but rather a simple SQL mapper. The downside to my approach is that you need to write a lot more code (SQL), but I don't mind the trade-off.
Is there any possibility of upgrading to framework 3.5? if so take a look at LINQ to SQL and Entity Framework as this will accomplish alot of this for you.
If not then as long as it generates standard code that doesnt tie you into 3rd party libraries then you could certainly use it. At my workplace we have our own generator similar to this and it works well although we will shortly be moving to LINQ to SQL.
There are many ways of wrapping a database table in a C# class; you probably want to investigate a few alternatives before choosing between the one you've linked to and the Entity Framework.
There's a software pattern called the "active record pattern" which describes exactly this approach - one C# class for each table, with load/save methods like Customer.GetById(), Customer.Save(), and so on.
For ASP.NET 2.0, check out the Castle Project's ActiveRecord implementation and a third-party Visual Studio plugin tool called ActiveWriter that lets you generate class wrappers for your tables using a drag'n'drop interface.
You will need to determine at what point you need sets of data that are composed from your tables, and whether you want SQL to produce these with stored procedures or if your business logic layer will handle these. As Dr8k says, nHibernate will create SQL for you, but there is a learning curve with nHibernate. The ORM will be in control of how you are getting the data and depending on your environment and DBA's conmfort level you may other issues to overcome.
If you more comfortable with SQL, then there is another tool called SubSonic that will create wrappers ala Active Record for you while offering you the ability to use stored procedures as well. There is also a nice query tool with a fluent interface that you can use if you are not able to use LINQ.