|
| |
User Groups : Forums : SiteExperts :
Microsoft .NET
:  |  Persist object to a database?
Ok, I was talking to a colleague of mine, and this conversation evolved from Stored Procedures into object persistence.
My colleague (who is EXTREMELY knowledgeable) is a Java guy, and I'm more of a .NET guy (but I'm learning several different languages).
Anyway, I was asking him recently about using stored procedures in a project, and he told me that using stored procedures is no longer a best practice, and that a "persistence framework" is now a best practice (something like NHibernate).
My thinking at that point was this "persistence" he spoke of was something akin to the way someone can update a database with ADO.NET, like the following (some code excluded for brevity):
// #########################
// UPDATE.
// #########################
DataRow targetRow = dataTable.Rows[index];
Application.DoEvents();
targetRow.BeginEdit();
targetRow["MyField"] = txtSomeText.Text;
targetRow.EndEdit();
DataSet DataSetChanged = DataSet.GetChanges(DataRowState.Modified);
DS.Merge(DataSetChanged);
DataAdapter.Update(DS, "TableName");
DS.AcceptChanges();
Apparently, according to my colleague, this is not the case.
He provided me the following (it's in Java):
EntityManager em;
public void createCustomers()
{
Customer c = new Customer();
c.setCustomerID(1);
c.setFirstName("John");
c.setLastName("Doe");
em.persist(c);
}
Then to load a customer you would do this:
EntityManager em;
public Customer getCustomer(int id)
{
Customer c = em.find(Customer.class, new Integer(id));
return c;
}
The plumbing is handled by the framework, and no explicit DB IO occurs.
He followed that up with:
The call to EntityManager.persist(Object) stores the object in the DB. The call to EntityManager.find(Class, Key) retrieves it. So nothing in particular happens when the object is destructed - just when you make those persistence calls. The persistence framework builds a table on the back end that looks a lot like the object. Classname = tablename, attributeNames = rowNames, etc.
My question to him at that point was:
Ah, so it still hits a DB, it just does it in a different way?
To which he responded:
Yes, it totally encapsulates DB stuff. All you have to do is create an object and tell it to persist. Everything else is done and you never see it. It's like your objects know how to store themselves.
-------------
So my question is this: Is there something like this in .NET (preferably C#)? If so, could someone point me to an example? I've got a couple of projects written down, and I want to start working on them, and I'd like to try this as an experiment.
Any help would be greatly appreciated. Started By Monte on Jun 8, 2010 at 10:14:46 AM | | | 4 Response(s) | Reply |
| Earlier Replies | Replies 1 to 4 of 4 | Later Replies | | | brian on Jun 9, 2010 at 1:08:53 AM (# 1) Persistence is just another word for storage - don't let it fool you in the slightest. NHiberbnate is just a code layer or library for .NET that handles a lot of the so-called 'persistence' for you. Sometimes these things can be good but sometimes it's good to develop your own. The idean between NHibernate is that it creates objects based on your database storage so one table one object. Sometimes this works, sometimes not, especially if you need 3 or 4 different objects joined together as a single entity for performance, binding or whatever.
Personally, I put together a data class then objects that need to hit the database inherit from it and it wraps, in a generic manner, commands and queries so it would be relatively easy to replace the data class for one with another database or 'persistence engine' *shudders*.
Stored Procedures: I've heard people they are not the way to go and it depends. Stored procedures have loads of advantages over standard queries, the main ones being they can deal with very complicated interactions with the database, they require reduced security on the database and they can themselves be encrypted. They also have performance advantages over 'embedded' queries although I am lead to believe that this is less in modern versions of Sql Server. (sorry, assuming you are referring to MSSQL here)
As a rule, for accessing a table you need about 3 procedures to handle storing, selecting and deleting. If you use defaulted parameters, stores can do both inserts and updates depending on parameters supplied, select procedures can get 1 or many records and the delete can do whatever it needs to. still, you end up with 3 procedures minimum.
Downsides would be cross-database support - difficult to support on different platforms e.g. oracle stored procedures have to be named with less than 30 ch names. Also, it's a separate code-base to support, something I personally don't have a problem with.
If you embed sql in the code, parameterise them. This prevents injection attacks, something I've unfortunately had the pain of experiencing in the past. Parameters are the key to security.
The downside of embedded SQL is that if you need to perform inserts, updates and deletes the user/role needs the access to the table to perform this. This makes the database itself more vulnerable to attack. Also, it can make for messier code.
There is a third option, LINQ or more specifically LINQ to SQL. This has some great advantages in that you can use queries to join sql tables to ArrayLists or stuff like that (so I believe anyways) and many other cool things too.
I can't say I have the opportunity to use it much but if I did, I would.
And extremely knowledgeable Java programmer? isn't that like Military Intelligence? ;)
bablind on Jun 9, 2010 at 1:53:41 AM (# 2)Give a try to Eloquera Database www.eloquera.com ( native .NET object database). It is written in C# (not ported from Java as many other database).
It has a very good performance and it is FREE for commercial use.
matspca on Feb 2, 2012 at 8:44:50 PM (# 3)Try the World's fastest, most scalable pure C# database system, http://www.VelocityDB.com
It is also easy to use, with a rich set of API and uses 64 bit object identifiers.
andrewpattinson on Aug 12, 2012 at 10:42:33 PM (# 4)Here is way to do this. Object/Relational (O/R) mapping tools are sophisticated tools that map objects to rows in a relational database, obviating the need for a complicated persistence layer and minimizing, and in most cases eliminating, the need for developers to write any SQL.
http://www.dapfor.com/en/net-suite/net-grid/tutorial/data-sorting
| | Earlier Replies | Replies 1 to 4 of 4 | Later Replies |
To respond to a discussion, you must first logon.
If you are not registered, please register yourself to become a member of the SiteExperts.community.
|
