Data Access Interfaces, Mapping and Domin model

[Kevin C]

I was curious to know what some developers out in the industry are doing when it comes to exposing Data access logic, specifically persistence. This is assuming that your not using an O/R framework or something that completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to "know" about the domain model. I understand the fact that a change to the model can have a rippling effect, but personally the maintenance ease of sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped within the BAL or does your DAL perform the mapping. Again, from readings, idealistically the mapping should *not* occur in the DAL. Instead it should be done by the business layer. But if you move forward with a domain model approach and allow your DAL to know about the domain model you will already require a reference to the domain model lib. In that case, why not build a generic base DAL that know how to build the business entities in a structured common way. Odds are that since u are using the domain model approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this style. Am I crazy here? The last system I worked on was built like this and by the time we were done we knew it forward and backward and it was a breeze to work with. BUT, we did things in which the DAL created the business entities and the DAL was aware of the business entities. Hind site I am questioning that; at the same time I personally thought it was easy to maintain and have since heard ( I left there ) that they are really pleased with it and the maintenance is easy.

Kevin C

 

[Kevin C]

Sorry, here is the link I was referring to http://www.devx.com/vb2themax/Article/19892/0/page/2 .
I was curious to know what some developers out in the industry are doing when it comes to exposing Data access logic, specifically persistence. This is assuming that your not using an O/R framework or something that completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to "know" about the domain model. I understand the fact that a change to the model can have a rippling effect, but personally the maintenance ease of sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped within the BAL or does your DAL perform the mapping. Again, from readings, idealistically the mapping should *not* occur in the DAL. Instead it should be done by the business layer. But if you move forward with a domain model approach and allow your DAL to know about the domain model you will already require a reference to the domain model lib. In that case, why not build a generic base DAL that know how to build the business entities in a structured common way. Odds are that since u are using the domain model approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this style. Am I crazy here? The last system I worked on was built like this and by the time we were done we knew it forward and backward and it was a breeze to work with. BUT, we did things in which the DAL created the business entities and the DAL was aware of the business entities. Hind site I am questioning that; at the same time I personally thought it was easy to maintain and have since heard ( I left there ) that they are really pleased with it and the maintenance is easy.

Kevin C

 

[Nicholas Paldino [.NET/C# MVP]]

Kevin,

I used to subscribe to something akin to 1 and 2, but I found that it is
very, very difficult to keep everything in sync, and the idea of going "up"
one level was bothersome to me.

However, with .NET (specifically VS.NET), I've found it much easier to
justify 3. In previous versions of VS.NET, you could create a typed dataset
based on a data source in your system. I would then pass this across all
layers for my needs, almost having each layer act as a filter as the typed
dataset moves from one layer to the next.

Now, with VS.NET, it makes it even easier. When you create a dataset,
it will not only create adapters like it did before, but it will allow you
drag stored procedures onto the dataset. Now I wouldn't advocate attaching
them to the data structure, but you can have them exist as separate object
entities. The designer also creates interfaces on the objects it creates,
which helps again.

Now, if you go the typed dataset route (or the dataset route), you can
make your data layer even more abstract. Personally, I like to follow the
following pattern:

- For each table in the entity, define a standard set of stored procedures
for CRUD operations. I prefer xsp_<table name>_Insert for insert,
xsp_<table name>_Update for update and xsp_<table name>_Delete for delete.
You can define others, but for the most basic of data layers, this is the
minimum.

- Have a function in your data layer which takes the data table, determines
the changes (through the GetChanges method) and creates the appropriate data
adapters (based on the tables in the set). Because of the table names in
the data set, you should be able to get the stored procedure information
easily, and construct the command dynamically.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)



I was curious to know what some developers out in the industry are doing
when it comes to exposing Data access logic, specifically persistence. This
is assuming that your not using an O/R framework or something that
completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about
the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string
phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain
model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to
"know" about the domain model. I understand the fact that a change to the
model can have a rippling effect, but personally the maintenance ease of
sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped
within the BAL or does your DAL perform the mapping. Again, from readings,
idealistically the mapping should *not* occur in the DAL. Instead it should
be done by the business layer. But if you move forward with a domain model
approach and allow your DAL to know about the domain model you will already
require a reference to the domain model lib. In that case, why not build a
generic base DAL that know how to build the business entities in a
structured common way. Odds are that since u are using the domain model
approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this
style. Am I crazy here? The last system I worked on was built like this
and by the time we were done we knew it forward and backward and it was a
breeze to work with. BUT, we did things in which the DAL created the
business entities and the DAL was aware of the business entities. Hind site
I am questioning that; at the same time I personally thought it was easy to
maintain and have since heard ( I left there ) that they are really pleased
with it and the maintenance is easy.

Kevin C

 

[Kevin C]

Ahh, i see. Here is a thing that maybe you can explain to me then. If you
are using typed datasets then how do you handle master detail relationships.
For example, you have a customer detail typed dataset, customerData.xsd.
That customer has orders, orders are all around the system so you create
CustomerData.xsd. Now one service interface is GetCustomerDetail,
returning the simple CustomerData dataset here is easy. Then there is a
GetCustomerOrders. The data return needs to be both customer info and order
info .. how do you do that when you have 2 *dataset* defined? It seems that
the fact that they are both defined as datasets is an issue.
Of course I could go define a new dataset than has both but where's the
benefit there. Then I just end up with a gazillion data tables .... or is
that the idea??

Kevin

Kevin,

I used to subscribe to something akin to 1 and 2, but I found that it is
very, very difficult to keep everything in sync, and the idea of going "up"
one level was bothersome to me.

However, with .NET (specifically VS.NET), I've found it much easier to
justify 3. In previous versions of VS.NET, you could create a typed dataset
based on a data source in your system. I would then pass this across all
layers for my needs, almost having each layer act as a filter as the typed
dataset moves from one layer to the next.

Now, with VS.NET, it makes it even easier. When you create a dataset,
it will not only create adapters like it did before, but it will allow you
drag stored procedures onto the dataset. Now I wouldn't advocate attaching
them to the data structure, but you can have them exist as separate object
entities. The designer also creates interfaces on the objects it creates,
which helps again.

Now, if you go the typed dataset route (or the dataset route), you can
make your data layer even more abstract. Personally, I like to follow the
following pattern:

- For each table in the entity, define a standard set of stored procedures
for CRUD operations. I prefer xsp_<table name>_Insert for insert,
xsp_<table name>_Update for update and xsp_<table name>_Delete for delete.
You can define others, but for the most basic of data layers, this is the
minimum.

- Have a function in your data layer which takes the data table, determines
the changes (through the GetChanges method) and creates the appropriate data
adapters (based on the tables in the set). Because of the table names in
the data set, you should be able to get the stored procedure information
easily, and construct the command dynamically.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)



I was curious to know what some developers out in the industry are doing
when it comes to exposing Data access logic, specifically persistence. This
is assuming that your not using an O/R framework or something that
completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about
the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string
phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain
model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to
"know" about the domain model. I understand the fact that a change to the
model can have a rippling effect, but personally the maintenance ease of
sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped
within the BAL or does your DAL perform the mapping. Again, from readings,
idealistically the mapping should *not* occur in the DAL. Instead it should
be done by the business layer. But if you move forward with a domain model
approach and allow your DAL to know about the domain model you will already
require a reference to the domain model lib. In that case, why not build a
generic base DAL that know how to build the business entities in a
structured common way. Odds are that since u are using the domain model
approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this
style. Am I crazy here? The last system I worked on was built like this
and by the time we were done we knew it forward and backward and it was a
breeze to work with. BUT, we did things in which the DAL created the
business entities and the DAL was aware of the business entities. Hind site
I am questioning that; at the same time I personally thought it was easy to
maintain and have since heard ( I left there ) that they are really pleased
with it and the maintenance is easy.

Kevin C

 

[Nicholas Paldino [.NET/C# MVP]]

Kevin,

That kind of is the idea. It comes down to how you define your
relationships. For this situation, you have a number of options. I
personally would include orders in the datastet with the customers, as they
are related pretty tightly. You then only have to pass one dataset to your
data layer to be modified. This allows for a greater degree of generality
when designing your data layer.

If you feel they should be in separate data sets, then you can always
modify your data layer to accept two data sets per operation and then have
it work on that.

However, because I would always have my data layer running within some
transactional context, there is nothing that says I can't call the data
layer twice to perform the operations on each data set.

Personally, I like to indicate whether a relationship is an owned
relationship or not (if an audit occurs on a record then all children that
are related to that record are audited as well). If it is owned, then I
think that it should be in the same data set. In this case, I think that a
customer owns the orders, but that's a decision you have to make.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Ahh, i see. Here is a thing that maybe you can explain to me then. If
you
are using typed datasets then how do you handle master detail
relationships.
For example, you have a customer detail typed dataset, customerData.xsd.
That customer has orders, orders are all around the system so you create
CustomerData.xsd. Now one service interface is GetCustomerDetail,
returning the simple CustomerData dataset here is easy. Then there is a
GetCustomerOrders. The data return needs to be both customer info and
order
info .. how do you do that when you have 2 *dataset* defined? It seems
that
the fact that they are both defined as datasets is an issue.
Of course I could go define a new dataset than has both but where's the
benefit there. Then I just end up with a gazillion data tables .... or is
that the idea??

Kevin

in
message news:[email protected]...

Kevin,

I used to subscribe to something akin to 1 and 2, but I found that it is
very, very difficult to keep everything in sync, and the idea of going "up"
one level was bothersome to me.

However, with .NET (specifically VS.NET), I've found it much easier
to
justify 3. In previous versions of VS.NET, you could create a typed dataset
based on a data source in your system. I would then pass this across all
layers for my needs, almost having each layer act as a filter as the
typed
dataset moves from one layer to the next.

Now, with VS.NET, it makes it even easier. When you create a
dataset,
it will not only create adapters like it did before, but it will allow
you
drag stored procedures onto the dataset. Now I wouldn't advocate attaching
them to the data structure, but you can have them exist as separate
object
entities. The designer also creates interfaces on the objects it
creates,
which helps again.

Now, if you go the typed dataset route (or the dataset route), you
can
make your data layer even more abstract. Personally, I like to follow
the
following pattern:

- For each table in the entity, define a standard set of stored
procedures
for CRUD operations. I prefer xsp_<table name>_Insert for insert,
xsp_<table name>_Update for update and xsp_<table name>_Delete for
delete.
You can define others, but for the most basic of data layers, this is the
minimum.

- Have a function in your data layer which takes the data table, determines
the changes (through the GetChanges method) and creates the appropriate data
adapters (based on the tables in the set). Because of the table names in
the data set, you should be able to get the stored procedure information
easily, and construct the command dynamically.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)



I was curious to know what some developers out in the industry are doing
when it comes to exposing Data access logic, specifically persistence. This
is assuming that your not using an O/R framework or something that
completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about
the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string
phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain
model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to
"know" about the domain model. I understand the fact that a change to
the
model can have a rippling effect, but personally the maintenance ease of
sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped
within the BAL or does your DAL perform the mapping. Again, from readings,
idealistically the mapping should *not* occur in the DAL. Instead it should
be done by the business layer. But if you move forward with a domain model
approach and allow your DAL to know about the domain model you will already
require a reference to the domain model lib. In that case, why not build a
generic base DAL that know how to build the business entities in a
structured common way. Odds are that since u are using the domain model
approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this
style. Am I crazy here? The last system I worked on was built like this
and by the time we were done we knew it forward and backward and it was a
breeze to work with. BUT, we did things in which the DAL created the
business entities and the DAL was aware of the business entities. Hind site
I am questioning that; at the same time I personally thought it was easy to
maintain and have since heard ( I left there ) that they are really pleased
with it and the maintenance is easy.

Kevin C

 

[Kevin C]

Nicholas,
The defining of the relationships is huge hole that I cannot seem to get
mentally filled when it comes to using typed datasets. To me, I think
defining the customer-order typed dataset is very limiting. There will be
more parts of the system that need just order information. At that time do
I create another typed dataset ... that is not good. Now I'm maintaining 2
orders in my system.

Kevin

Kevin,

That kind of is the idea. It comes down to how you define your
relationships. For this situation, you have a number of options. I
personally would include orders in the datastet with the customers, as they
are related pretty tightly. You then only have to pass one dataset to your
data layer to be modified. This allows for a greater degree of generality
when designing your data layer.

If you feel they should be in separate data sets, then you can always
modify your data layer to accept two data sets per operation and then have
it work on that.

However, because I would always have my data layer running within some
transactional context, there is nothing that says I can't call the data
layer twice to perform the operations on each data set.

Personally, I like to indicate whether a relationship is an owned
relationship or not (if an audit occurs on a record then all children that
are related to that record are audited as well). If it is owned, then I
think that it should be in the same data set. In this case, I think that a
customer owns the orders, but that's a decision you have to make.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Ahh, i see. Here is a thing that maybe you can explain to me then. If
you
are using typed datasets then how do you handle master detail
relationships.
For example, you have a customer detail typed dataset, customerData.xsd.
That customer has orders, orders are all around the system so you create
CustomerData.xsd. Now one service interface is GetCustomerDetail,
returning the simple CustomerData dataset here is easy. Then there is a
GetCustomerOrders. The data return needs to be both customer info and
order
info .. how do you do that when you have 2 *dataset* defined? It seems
that
the fact that they are both defined as datasets is an issue.
Of course I could go define a new dataset than has both but where's the
benefit there. Then I just end up with a gazillion data tables .... or is
that the idea??

Kevin

in
message news:[email protected]...

Kevin,

I used to subscribe to something akin to 1 and 2, but I found that

it
is

very, very difficult to keep everything in sync, and the idea of going "up"
one level was bothersome to me.

However, with .NET (specifically VS.NET), I've found it much easier
to
justify 3. In previous versions of VS.NET, you could create a typed dataset
based on a data source in your system. I would then pass this across all
layers for my needs, almost having each layer act as a filter as the
typed
dataset moves from one layer to the next.

Now, with VS.NET, it makes it even easier. When you create a
dataset,
it will not only create adapters like it did before, but it will allow
you
drag stored procedures onto the dataset. Now I wouldn't advocate attaching
them to the data structure, but you can have them exist as separate
object
entities. The designer also creates interfaces on the objects it
creates,
which helps again.

Now, if you go the typed dataset route (or the dataset route), you
can
make your data layer even more abstract. Personally, I like to follow
the
following pattern:

- For each table in the entity, define a standard set of stored
procedures
for CRUD operations. I prefer xsp_<table name>_Insert for insert,
xsp_<table name>_Update for update and xsp_<table name>_Delete for
delete.
You can define others, but for the most basic of data layers, this is the
minimum.

- Have a function in your data layer which takes the data table, determines
the changes (through the GetChanges method) and creates the appropriate data
adapters (based on the tables in the set). Because of the table names in
the data set, you should be able to get the stored procedure information
easily, and construct the command dynamically.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)



I was curious to know what some developers out in the industry are doing
when it comes to exposing Data access logic, specifically persistence. This
is assuming that your not using an O/R framework or something that
completely abstracts you from the persistence details.

Are you:
1. Having simple data type interfaces and the data layer know nothing about
the domain models. For example:

public int SaveCustomer( string fname, string lname, string ssn, string
phoneNumber)

2. While this may anger OO peeps, does your DAL know about the domain
model. For example:

public int SaveCustomer ( Customer customer )

3. Other, like generic datasets or typed datasets?

I am really interested in the decision whether or not to allow the DAL to
"know" about the domain model. I understand the fact that a change to
the
model can have a rippling effect, but personally the maintenance ease of
sharing these common objects across the enterprise makes is worthy decision.

Also, where are your business entities being created. Are they being mapped
within the BAL or does your DAL perform the mapping. Again, from readings,
idealistically the mapping should *not* occur in the DAL. Instead it should
be done by the business layer. But if you move forward with a domain model
approach and allow your DAL to know about the domain model you will already
require a reference to the domain model lib. In that case, why not

build
a

generic base DAL that know how to build the business entities in a
structured common way. Odds are that since u are using the domain model
approach any changes to the domain model will probably affect the DAL.

I think this guy is right on the $$$ with the tradeoffs but I like this
style. Am I crazy here? The last system I worked on was built like this
and by the time we were done we knew it forward and backward and it was a
breeze to work with. BUT, we did things in which the DAL created the
business entities and the DAL was aware of the business entities. Hind site
I am questioning that; at the same time I personally thought it was

easy
to

maintain and have since heard ( I left there ) that they are really pleased
with it and the maintenance is easy.

Kevin C