|
Subject:
|
custom entities vs typed DataSets (in Chapter 3)
|
|
Posted By:
|
patelc75
|
Post Date:
|
11/30/2006 8:07:12 PM
|
Marco lists the following as a disadvantage of typed datasets in Chapter 3 (pg. 55)
“...the thing that .NET developers lament the most is the fact that you can’t easily add your custom buisness and validation logic to a DataSet…”
My question is.. Can’t you do this with partial classes like explained in the following article:
http://www.theserverside.net/tt/articles/showarticle.tss?id=DataSetDesigner
Going Beyond the Designer
What if you want to use a data reader to populate a custom business entity instead of populating a data table? What if you want to execute some custom validation of a column value when it is changed by client code? Do these requirements mean you need to abandon the typed data set designer? Not necessarily. These things cannot be set up directly in the designer, but are fairly straightforward to add through partial class extensions. If you add a class to your data access layer project, and put the following code in it:
using System;
using System.ComponentModel;
using System.Data.SqlClient;
using System.Data;
namespace NorthwindDataAccess.EmployeesDataSetTableAdapters
{
public partial class EmployeesTableAdapter : Component
{
public SqlDataReader GetReader()
{
return Adapter.SelectCommand.ExecuteReader(
CommandBehavior.CloseConnection);
|
|
Reply By:
|
englere
|
Reply Date:
|
12/1/2006 7:30:44 PM
|
That's a great article, and one of my favorite sites. I have this debate with developers in my community on a regular basis, and there's no such thing as a right answer - that's why we enjoy the debate. If it were a slam-dunk we'd quickly grow tired of the subject.
One of our local experts wrote a book on ADO.NET and he's a strong proponent of leveraging the DataSet in advanced ways. I'm of the other school of thought that says custom is better, unless you have a trivial requirement.
In my mind, people who wrap the DataSet are locking themselves to an object they have no control over, and might change in incompatible ways in the future. You're also locking yourself down to .NET rather strongly, and causing trouble with web services in the future.
Rolling-your-own isn't so hard when you write code generation programs. I like these as addins to Visual Studio. This improves productivity and makes the custom method easier than wrapping DataSets for your regular application programmers.
Choose the option that makes the most sense to you, and the one that lets you sleep best at night. Sleep is a good thing!
Eric
|
|
Reply By:
|
patelc75
|
Reply Date:
|
12/5/2006 5:37:43 PM
|
Eric,
thanks for the response!
You say that "people who wrap the DataSet are locking themselves to an object they have no control over".
My question is: Isn't this lack of control possible to overcome with these partial class extensions listed above?
I understand it locks you down to .NET but it does allow all the control you could want.
Chirag
|
|
Reply By:
|
englere
|
Reply Date:
|
12/5/2006 7:02:13 PM
|
If I don't have the source for an object, then it's not mine. I don't like the idea of injecting new functionality (other than simple inheritance) into objects I don't own, although a lot of people do. You may want to check out Aspect Oriented Programming. This is not my cup of tea, but you might like it.
AOP developers constantly seem to be intercepting and injecting. There's a class of problems where this is the best solution, but whether it should be applied more generally is open for debate.
I don't mind using stock objects that I don't have the source for, but I don't want to inject or wrap my own extensions into an object that wasn't intended to be extended in this manner. I'm not saying it's wrong for you, but it would be wrong for me.
Any further discussion of this topic should take place after injesting a couple adult beverages in an appropriate setting. Some people argue about football on a Saturday afternoon at the pub, but I sit at the table and argue about software design patterns and methodologies - you're right, I need a life :-)
Eric
|
|
Reply By:
|
David Gadd
|
Reply Date:
|
12/11/2006 8:38:30 PM
|
I'm currently working with .NET 2.0 typed datasets after previously working with Hibernate. Something that I was accustomed to doing in Hibernate, I can't figure out how to do in typed datasets, namely, adding to an association.
For example, given an xsd file named CustomerAggregate.xsd containing a Customer and Invoice classes (and Invoice has a foreign key many-to-one relationship to customer), how do I do this?
SqlTransaction transaction = customerAdapter.BeginTransaction(connection);
customerAdapter.FillByCustomerID(customerAggregate.Customers, customerID);
invoicesAdapter.FillByCustomerID(customerAggregate.Invoices, customerID);
CustomerAggregate.CustomersRow customer = customerAggregate.Customers[0];
InvoicesRow[] invoices = customer.getInvoicesRows();
InvoiceRow invoice = new CustomerAggregate.InvoiceRow(); // NOT ALLOWED--HOW DO I DO THIS LINE??
invoice.Net = 250.00;
invoice.Tax = 27.52;
customerAggregate.Invoices.AddInvoicesRow(invoice);
customerAdapter.Update(customerAggregate);
transaction.Commit();
|
|
Reply By:
|
David Gadd
|
Reply Date:
|
12/11/2006 9:16:54 PM
|
Ah. I found it:
SqlTransaction transaction = customerAdapter.BeginTransaction(connection);
customerAdapter.FillByCustomerID(customerAggregate.Customers, customerID);
invoicesAdapter.FillByCustomerID(customerAggregate.Invoices, customerID);
CustomerAggregate.CustomersRow customer = customerAggregate.Customers[0];
InvoicesRow[] invoices = customer.getInvoicesRows();
customerAggregate.Invoices.NewInvoicesRow();
invoice.Net = 250.00;
invoice.Tax = 27.52;
customerAggregate.Invoices.AddInvoicesRow(invoice);
customerAdapter.Update(customerAggregate);
transaction.Commit();
|
