ADO.NET vs. Enterprise Java Beans [enterprise java beans] [strict structure]
Q: Hi all,
I am totally confused about ADO.NET, from the Java world.
Does ADO.NET has a strict structure as entity beans in Enterprise JavaBeans?
I just started working on access to the database, and read that data sets are the data. So somehow the code reception of the data set must somehow be able to select, delete, update, insert, just like entity beans. But I have not been able to structure such a sample shows how I can find. Can anyone help me?
Thanks for your answers.
Re:I'm sure there are plenty of such products for .Net but the question is, what's the standard API to do so with ADO.Net?
There's currently no syntactical elements in C# or otherwise to facilitate this, but it could certainly be extended using .NET's attribute facilities (for all languages) to implement this persistence layer. C# has the using statement which decomposes into an implicit reference to IDisposable.Dispose() for implementing objects, for instance. The same could be done for data access code that abstracts the classes of ADO.NET.
For example, let's say you've modeled a User entity in your domain. How would you map/persist that to an RDBMS?
I'm not quite sure I grok you on that one. Object state can be automatically serialized to any compliant RDBMS (or file) through a binary serializer, or a soap serializer. This could be implemented even at the data level to facilitate this implicit level of persistence. What you do not want, however, is implicit persistence of interim data changes from consuming classes, as this violates the integrity of the database. For instance, you wouldn't want a "half complete" transaction to be committed to the RDBMS, you'd want to serialize the object when you're finished with it, then deserialize it and commit the transaction. That's just one way of handling it, there are more efficient ways depending on how long you want to persist, what you want to persist, etc.. In Windows DNA vernacular, you'd probably be implementing this as a COM component within MTS/COM+ component that employes the property bag to persist the otherwise stateless objects.
Microsoft has been releasing "application blocks for .NET", and one of them is the Data Access Application Block (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp). To me, it looks like a port of the FMStocks' Windows DNA data access layer code to .NET, but it's still pretty clean. This doesn't do everything you're requesting, but it's a start, and it could be extended.
In response to your entity beans functionality in ADO.NET question, I honestly don't know if there's an equivalent. I assume you're referring to container-managed persistence of an entity bean, and although an ADO.NET DataSet does contain schema information, it's not independent of the data source. In other words, you can't always persist a DataSet and connect it to any data source and have it still generate the calls necessary to update the data. As you said, it's disconnected, and there are other facilities for this.
I'm rambling. Hope I made sense…
Re:J2EE professionals seem to dislike entity beans with a passion, for a variety of reasons.
guy,Thats a surprise, I've not been upto date with the news though. Why is that? 
guy, you are right about the multitude of books all talking about the same thing. But .Net is relatively new, so expect this kind of stuff on the market until the authors have learned a bit more of the technology 
I personally don't like the idea of a system that automatically updates the database for me, so no comments.
Nvm, thats not what I meant I guess since u have not worked with entity beans, you would not know what I was referring to.
Re:He wants a ready-made object-oriented persistence layer. I'm sure there are plenty of such products for .Net but the question is, what's the standard API to do so with ADO.Net?
SQL statements or stored procedures just doesn't cut it for a decent data layer API.
For example, let's say you've modeled a User entity in your domain. How would you map/persist that to an RDBMS?
FWIW, a lot of J2EE professionals seem to dislike entity beans with a passion, for a variety of reasons.
Re:Actually I find that the biggest problem with .NET is that too many books out there try to serve as a general study guide to .NET as a whole.
That's somewhat understandable because .NET is new but there are far too many .NET books out there. The only other technology that comes almost as close to the hype of .NET is XML.
There are more books being released on more specialized topics but we still need more books of these kinds.
For instance, in java entity beans, all we have to do is follow some structure of code, and when this object is instantiated with data from the database, all modification made to the object's attributes is automatically updated to the database by the system.
I don't quite understand what you mean by this and I personally don't like the idea of a system that automatically updates the database for me, so no comments. 
Re:Thx all for ur replies.
guy, what I was looking for, is whether there is a facility in .NET which will automatically manage the Datasets.
For instance, in java entity beans, all we have to do is follow some structure of code, and when this object is instantiated with data from the database, all modification made to the object's attributes is automatically updated to the database by the system.
From what I have gathered on the net, ADO.NET does provide a better service than JDBC through the DataSet. In fact, DataSet being a persistent object of data on its own means that ADO.NET is capable to act to a certain extent as an entity bean. There is something called a command builder which does facilitate updates by generating the appropriate sql command though. Im still looking into it…
The problem with MS .NET is everything is given in bits and pieces. Being accustomed to some code structure like in EJBs, I find it hard to come to terms with my own coding. I find it kind of messy to code anyhow. I do prefer a standard. I guess Im a Java freak
Re:I'm not a .Net developer but DataSet, the central interface in ADO.Net, appears to be higher level than JDBC, but lower level than JDO or Entity Beans. Entity beans appear to be much stronger managed components to me, but then again I'm not an expert in any of these technologies.
CMP entity beans aren't quite powerful enough yet, but it's quite a convenient programming model for the consumer.
Re:I haven't a clue about the Java equivalent for ADO.NET, but the DataSet object is a relational database in its own rights. It may contain tables, columns, rows and data relations just like any other relational database. DataSet is very powerful and makes it even easier to complete separate the Data layer components from their original data store.
Re:coming from the Java/ejb world myself, i don't know the answer to your question either, but i'm interested to hear from some .NET person.
anyone??
Related posts
Tags: enterprise java beans, strict structure