|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 10
Messages: 10
Messages: 10
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Persistent Objects
Einar Ingebrigtsen writes about object-relational persistence, and how one could approach building their own O/R layer making use of some of the .NET platform's feature set to make it easy to do so.
Read Persistent Objects
|
|
|
Message #135875
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
misunderstanding
One of the things that are cool with .net Framework 2.0 is the ObjectSpaces. For JAVA developers this has been available for quite some time through libraries such as Hibernate. Today you get Hibernate for .net and there is also a free Objectspaces library for .net 1.1. The only thing with both these that I really find a bit odd is that they rely on XML files to configure the classes and properties to be connected to the datasource. I think there is a major mis-understanding about why the mapping is externalized in an XMl format. Not all system use one monolithic database model that is under your own control. In big applications, you have to acccess data in multiple databases ranging from BTree to flat files to RDBMS. Correct me if I am wrong, but using a metadata approach would rapidly become gross and unmanageable using metadata approach. If you're app is that simple, then by all means use metadata. If the requirements change rapidly, or you have to integrate with other data sources then externalized metadata would provide a better way of mapping one set of domain objects to multiple sets of data models.
|
|
|
Message #135923
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persistent Objects
First, a clarification:
ObjectSpaces won't be in 2.0 and ObjectSpaces will most likely look totally
different from any betas made available so far.
Please see:
http://msdn.microsoft.com/data/objectspaces.aspx
This is a nice looking approach but it has a couple of disadvantages:
-it is slow, because of the proxy subsystem
-it is bound to property persistence, fields are per se not persistable
-...
In Java these disadvantages were solved by a superior approach:
byte code (i.e. intermediate language) enhancement.
This is around for years in Java now and even standardized (JDO specification:
Java Data Objects). FastObjects .NET offers this approach too for the .NET world (supported backends by now: SQL Server, Oracle, DB2, own OO-backend)
With intermediate language generation real transparent persistence is possible.
E.g. the example would reduce to:
[Persistent]
public class Customer
{
string name;
}
Intermediate language generation is more performant then reflection based (including this proxy example) persistence solutions.
There is no reflection needed, because each class gets invisible methods inserted, that are responsible for retrieving or storing the object.
All field types are supported (primitives, references, System.Collection classes) *without* the need for special holder or collection classes.
Of course inheritance and polymorphism is supported, too.
References are always delayed loaded on access, without requiring the user to perform some special action. Furthermore the framework tracks automatically, which objects have been modified and which not.
So comparing all these approaches, intermediate language generation offers the fewest restrictions for the object model of the user and the best performance.
For a more detailed technical discussion of several approaches you can read the article in "dot.net magazin" (German) issue 5/2004: "Be persistent"
Best regards,
Christian Romberg
Versant Europe
|
|
|
Message #135926
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Bytecode modification
Hi Guys
If people want to see how bytecode modification might work, I've put a very early cut of a proof of concept up on the gotdotnet site. Search for "bytecode" in the user samples.
I've got a version now which works with generics and the 1.2 framework, but bugs in the 2.0beta are preventing me releasing an update at this time.
Interestingly, you can use data flow analysis to automatically taint the objects which have been changed by determining when code is executing which results in a change to the object and adding additional code to update the taint on the object. Our DFA can handle taints to fields, arrays using pointers loaded from fields, structs, and structs in arrays loaded from fields.
Joel
|
|
|
Message #135980
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Files vs Reflection
Somebody told me that the reflection api in .NET is one of the slowest, i wonder how true that is, i also wonder if its going to be slower than reading mapping from an external file. external storage of the mapping might be better when it comes to changes in the db schema as compared to having to recompile code with the
metadata included.
i built a stored-proc to object mapper for sql server using reflection, i'm considering changing the maaping information to use external xml files. and speed might just be an issue
|
|
|
Message #136086
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persistent Objects
The approach I describe is surely most applicable in smaller applications and a solution that is targetted towards developers and not DBAs.
I read somewhere that most software development companies consist of 1-2 developers. Taking that into consideration, they are most likely putting together their own database schema.
The thing I find limiting with other solutions out there is the ability to link to other datasources and even create your own datasources. In the library I'm developing I've extended this to be more open.
http://blog.dolittle.com/PermaLink.aspx?guid=962200df-1a5f-47d6-a2ed-57eb23871832
One of the things that I will be including in the project is the ability to model your database schema in the application and have the schema automatically created on the datasource in runtime. This is a feature I've been using in other projects and proves to a be a very effective way for our development team (4 programmers) to keep our customer databases up to date. When we ship our product or updates of the product the schema is automatically updated with the latest changes.
But again, all these features are most likely to be most helpful in those scenarios where the developer is also the DBA.
|
|
|
Message #136142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persistent Objects
The approach I describe is surely most applicable in smaller applications and a solution that is targetted towards developers and not DBAs. I read somewhere that most software development companies consist of 1-2 developers. Taking that into consideration, they are most likely putting together their own database schema. The thing I find limiting with other solutions out there is the ability to link to other datasources and even create your own datasources. In the library I'm developing I've extended this to be more open. http://blog.dolittle.com/PermaLink.aspx?guid=962200df-1a5f-47d6-a2ed-57eb23871832One of the things that I will be including in the project is the ability to model your database schema in the application and have the schema automatically created on the datasource in runtime. This is a feature I've been using in other projects and proves to a be a very effective way for our development team (4 programmers) to keep our customer databases up to date. When we ship our product or updates of the product the schema is automatically updated with the latest changes. But again, all these features are most likely to be most helpful in those scenarios where the developer is also the DBA. I don't know about others, but sure seems like the author is re-inventing the wheel and making all the same mistakes others have made with OR mapping. I've seen this one too many times and I'm sure others have also.
Having a tool auto-generate your database schema is not new and has been a standard part of large scale development for a while. J2EE has has this stuff for quite a while also. If you can write a tool to auto-generate the database, why couldn't you auto-generate the mapping in an external file. Using metadata attributes within a class to do the mapping fails for several reasons. What happens if you want to be able to change which db table the object loads from a real table to a materialized view? What happens if the data is coming from some other data source or possibly XML. Even if an application starts out with a simple data model the team control, the model will evolve and the needs will grow. Don't take my word for it. There's hundreds of articles and examples all over the internet covering this topic. Google is your friend.
|
|
|
Message #138001
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A goog idea, even better if using interface
We are trying a similar approach, but using interfaces to de-couple the objects and persistent rules, e.g.
public class Customer
{
public string Name { get {...} set {...} }
}
can be retrieved from SQL server using
[PersistentObject(type=SQL, ....)]
public interface ICustomerForSql
{
[PersistentProperty] // SQL table, column related information
public string Name { get ; set;}
}
and to be persistent to a XML storage
[PersistentObject(type=XML, ....)]
public interface ICustomerForXml
{
[PersistentProperty] // XML node, attribute related information
public string Name { get ; set;}
}
The mapper uses the object instance as for data and the interface as for persistent instructions.
Customer customer = Mapper.Select("id=1", typeof(ICustomerForSql)) as Customer;
Mapper.Insert(customer, typeof(ICustomerForXml));
The idea is that an O/R mapper should not require anything from its client objects that are to be persistent, neither to be sub-classes of ContextBoundObject, nor to be decorated with persistent oriented attributes. Besides, objects to be persistent do not necessarily know the persistent targets.
|
|
|
Message #139041
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Persistent Objects
I agree with Peter - surely putting the mapping information into the compiled class source makes the whole persistence framework redundant.
The mapping should be external, easily configurable (i.e. through "human-readable" xml files), and updateable in runtime, not design-time.
I've worked on projects where we've gone through an entire persistence lifecycle starting with simple object serialization and ending with complex SQL databases without having to change the source of the core entities. Furthermore, entities should not be aware of their own persistence - that's the job of a data access framework - which should itself be configurable.
|
|
|
| Top posters of the weekTop posters of the weekTop posters of the week |
|
|
This list contains the members who have made the most posts in all forums over the
last 7 days:
- Karissa Sin
- sherazam khan
- Mike Liu
- Core Lab
|
|
Hot threads
Hot threads
Hot threads
|
More hot threads
More hot threads
More hot threads
|
|
Speaking at EclipseCon 2006, Java developer and independent consultant Madhu Siddalingaiah compared Microsoft's Visual Studio IDE to the open source development environment of Eclipse.
(33 comments,
last posted
March 09, 2010)
In this tech talk, Microsoft's Peter Provost talks about the design of the Composite UI Application Block and how the p&p team has led Microsoft in the adoption of Agile methodologies.
(0 comments,
last posted
April 17, 2006)
Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents patterns that describe when and how to design classes, constructs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.
(2 comments,
last posted
July 07, 2006)
Paul Ferrill caught up with prime open-source .NET applications driver Miguel De Icaza at Novell's BrainShare conference last week. They discussed the status of Windows Forms for Mono (it's coming along) and VB.NET for Mono (it looks like it's out).
(5 comments,
last posted
March 30, 2006)
In this tech talk, Microsoft Visual Studio architect Jack Greenfield discusses the company's approach to Domain-Specific Languages, or DSLs, and the part they play in software factories.
(0 comments,
last posted
March 15, 2006)
More hot threads »
|
|
