DAL design, assemblies and OO ?(s)

[Steve]

Hi all,

I'm designing my DAL layer(s) for our suite of applications and I'm
designing myself in circles, it's gotten to the point where each idea just
mixes me up more

We have 3 loosely related applications and I would like to use an assembly
for the DAL in each of them. I have thought of using a single assembly for
all of them with several different classes for providers/application
specific code, thought of a separate assembly for each application, etc.

I have several questions that I'm hoping will lead to some clarity if I can
get them answered and hopefully you can help with some of the answers.

1) Is there a way to share .cs files across several projects? I'm used to
this with C++, but in c# it seems that this results in a copy of the files
into each project. Is there a way to reference a file from another project?
or just a file by itself?

2) Typically, do companies use one giant DAL assembly for all applications
needing a DAL?

3) From what I understand of things, if I wanted to have 3 DAL assemblies
all inheriting a common "base DAL" class, I would have a total of 4
assemblies. Is that correct? 1 base DAL assembly, then 3 more assemblies
for each application?

4) Check out my little inheritance thing below, question will follow:
class DALBase
abstract class DAL_AppCommon : DALBase
class DAL_AppCommonMySql : DAL_AppCommon
class DAL_AppCommonSqlServer : DAL_AppCommon

abstract class DAL_AppInventory : DALBase, DAL_AppCommon
class DAL_AppInventoryMySql : DAL_AppInventory
class DAL_AppInventorySqlServer : DAL_AppInventory

What I'm trying to achieve is to have a concrete instance of say...
DAL_AppInventory and have it inherit the appropriate DAL_AppCommon derived
class. In other words, if I Instantiate DAL_AppInventoryMySql, I would like
it to also have the DAL_AppCommonMySql methods/properties.

I know that I can create a factory for each DAL_App* class and then have a
instance member of DAL_AppCommonMySql in my DAL_AppInventoryMySql, but I
would rather do this with inheritance if possible. I hope that makes sense.


General pointers/tips/clues VERY welcome.

Thank you for reading,
Steve

 

[rh.krish]

Hi Steve,
Here are the answers:
1. Unlike c++, you cannot reference a c# file. Reference is done at
the assembly level.
2. It depends. It's better to have it in single assembly by properly
structuring. You can abstract all common data access code to one sigle
file with static/shared method and one file each for you business
objects. By this way, you will get clean segregation.
3. What I believe from your writing is - you are trying to implement
providers for different databases such as MySql, SqlServer,
etc...Instead of reinventing the wheel, I would suggest you to go for
Microsoft Enterprise Library (available for both .NET 1.1 & 2.0 from
http://www.microsoft.com/practices ). This library has implentations
for SqlServer and Oracle and you can plug your imlementation for OleDb,
if you have or get from the internet. It's very easy and it reduces
70-80% of your code.

Hope this clears.

Regards,

Hari.

 

[pitdog]

Steve,

Please look at the Enterprise Libraries. I once attempted the same
thing you are and it ended up not working so well. The Enterprise
Libraries will make you happy.

PD

 

[pitdog]

Steve,

Please look at the Enterprise Libraries. I once attempted the same
thing you are and it ended up not working so well. The Enterprise
Libraries will make you happy.

PD

 

[Kevin Spencer]

I have no problem with the Enterprise Libraries. They are a time-saver, for
sure. However, without understanding the priniciples involved in designing
them, they are only a temporary convenience.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.

 

[Kevin Spencer]

Hi Steve,

1) Is there a way to share .cs files across several projects? I'm used
to this with C++, but in c# it seems that this results in a copy of the
files into each project. Is there a way to reference a file from another
project? or just a file by itself?

As a C++ programmer, some of this may sound elementary to you, but bear with
me, if you will.

A project is (essentially) a tool for creating an assembly. An assembly can
span multiple DLLs, but usually they do not. A file is a tool for creating a
namespace, a class, or classes, and/or other .Net programming entities. A
solution is a combination of projects, which creates a combination of
assemblies that comprise the various elements of an application, service, or
other solution to a set of requirements.

So, if you want to create a DAL, you don't necessarily want to create 3
different DAL projects. You may only need to create one. In particular, if
you're thinking of sharing a single file between multiple projects, it
sounds for all the world as if you want to create an assembly that can be
used by different solutions. For example, if you are always going to be
working from a single type of data provider, such as the .Net SQL Server
provider, exposed in the System.Data.Sql... namespaces, you will only need
one assembly with one namespace and one set of classes. On the other hand,
if you want your DAL to work with multiple and various data providers, you
may need a more complex structure, using inheritance, and/or a factory
pattern, such as is illustrated in the Microsoft Enterprise Library (see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/EntLib2.asp).
In fact, you can use the Enterprise Library straight out of the box, but I
would recommend studying it, so that you can, as you seem to want to,
improve your own design skills.

2) Typically, do companies use one giant DAL assembly for all
applications needing a DAL?

That depends upon the company, and upon the requirements and anticipated
requirements of the company.

3) From what I understand of things, if I wanted to have 3 DAL assemblies
all inheriting a common "base DAL" class, I would have a total of 4
assemblies. Is that correct? 1 base DAL assembly, then 3 more assemblies
for each application?

Not necessarily. See my earlier explanation. A single assembly can contain
multiple namespaces and classes. Whether it does or not is pretty much up to
you, and your requirements.

If you have Visual Studio.Net, take a look at the Object Browser. It will
give you a nice picture of the contents of various assemblies, and you can
get a lot of clues from Microsoft's solution as to how you might like to
structure your own.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
We got a sick zebra a hat,
you ultimate tuna.

 

[Steve]

Thank you for the suggestion, I have been playing with them here and there
or awhile now, very nice solution!

 

[Steve]

Wow, great email Kevin, thanks for taking the time to cover that.

Much of what you wrote was already known, but it's always helpful to revisit
things and think about them again.

As far as design skills go, I ran across a library over the weekend that is
utilizing many of the patterns I have read about in my various books. It's
called Composite Application Block. It took about 10 hours of looking over
this code and poking at it before I had my "Ohhhh, I get it. Cool!" moment


Anyway, I appreciate your email, it helped me lay things out a little more
in my head.
Have a good one,
Steve