Develop Reference

entity framework clarification about model objects and their methods

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

Confusion about selecting the suitable ORM?

I use ASP.NET with a informix database.
I use a set of written classes to handle the connections, the CRUD operations, transactions, etc....
Now, I feel these classes are not the best choice, less performance,take a lot of time and have many drawbacks.
I want to use an ORM, but I don't know how to choose the one which suits my web applications (ASP.NET, Informix).
Please help to select the convenient ORM.
I'm confused among nHibernate, Entity Framework, LINQ To SQL, and the Open Access (Telerik Component).
Note: I will use Visual Studio 2012 so I want the recent comparison.

I'd really suggest Entity Framework, as it is the native framework of .NET. Here it is stated that an Informix provider is available for EF.

Have you thought about using Fluent NHibernate? There's a wealth of articles on the web for it, and plenty on SO!! Here's one such article : converting to Fluent NHibernate sessionmanager.
EDIT :
Been thinking about your situation and I'll tell you how I usually think. Firstly, I'll think about exactly what it is I want my Gateway layer to do (this is the layer I use to talk to the persistance medium). Now, most will say, I want it to talk to the database or I want to insert and update stuff. But recently, I have found this isn't enough! Halfway through coding a gateway layer with these questions in mind, I suddenly realised that I wanted to do something ever so slightly different, and boom, I couldn't do it using NHibernate very easily. So, I made a few concessions and went with Linq-ToSql as it supported what was a higher priority requirement over some of the niceties of NHibernate.
Now, the reason for my tale is this : NHibernate provides some great little features like Result Transformation. I can have a view on my Db with masses of joined tables, giving an aliase for each field and with a lovely result transformer, bang, it's instantly transformed into my DTO. Now, don't get me wrong, Linq-To-Sql has a similar thing with the auto-generated classes. But I don't want these visible outside of the gateway layer (another conversation). Equally, Linq-To-Sql handles transactions with ease - something I thought NHibernate didn't do so well!
So, it all boils down to : what are my EXACT requirements within my gateway/repository layer and what technologies are compatible with my persistance medium?! And now, I can think about what technology I want to use.
I realise I may not have answered your question per se, but I hope it has given you something to think about!
Happy coding,
Cheers,
Chris.

http://www.ibm.com/developerworks/data/library/techarticle/dm-0903linqentity/
The link above will provide you with links to download the informix provider, as well as take you through a step by step process of using the informix provider in conjunction with Entity Framework.
More about Entity Framework
http://msdn.microsoft.com/en-us/library/aa697427(v=vs.80).aspx
Simply put, once you have this set up you will be able to create classes that map to your informix data structures and perform queries using linq. EF is quite a powerful and useful tool, I recommend it.

My vote is with Fluent NHibernate - you get the configurability and cross-platform usage of Hibernate but you get to obviate the necessity of using massive XML configuration files. Entity Framework is good, but I don't like tools which rely too much on IDE/Designer support.
Happy coding,
Mel

I'd recommend Fluent NHibernate. Personally I see it used in more companies than any other ORM framework.
I've used Entity Framework, both design-first, which has serious lock-in drawbacks, and code-first, which is okay.
I posted an answer on Code Review when someone was asking an almost identical question.

i think its better to read this book first :
http://www.wrox.com/WileyCDA/WroxTitle/Professional-ASP-NET-Design-Patterns.productCd-0470292784.html

Recommendation for creating DAL objects

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.

What is the best approach to make DAL?

I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
I've searched the internet and found some samples for this but I never know which is the best approach.
Is it to make [Attributes]? Or use <Generics> or something else?
So please just give me a head line and I'll go on from there.
Thanks again and forgive my language.

Just make sure you:
Always use stored procedures
Never use stored procedures
Sometimes use stored procedures
Use nHibernate
Use SubSonic
Use Entity Framework
Write your own
Never write you own
Use POCO
Use ActiveRecord
Use IRepository
Always do what Fowler says
Never do what Fowler says
Don't use Linq to SQL, it's dead
Use Linq to SQL, it's no longer dead
Do all that and you will be fine.

Best approach is:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
ORMs are incredibly hard to get right and a huge undertaking.
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/

I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.

If you are a starter I would recommend use of SubSonic (more so if you are on web development).

as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.

Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
Marc

Please read Data Access Layer Design Considerations

Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.

Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/

C# class from a SQL database table

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.