I am hoping someone can shed some light on a current topic of discussion with
all of our development managers.

All of our applications utilize 6 common objects; however we do not have
Common objects built.
For example all our applications have a Person object ( name, address(s),
phone(s), and a collection of attributes specific to the application ). These
“objects” may be a data table, dataset, or class file. Also, each application
has it own database.


My question is what would be the best way to architect this so that I am not
creating a copy of a base library project and changing out the DAL for each
application that is built.

Greg,

You give in my idea explicitly yourself the answer, however you have to do
with more subjective objects because you are writting of a pluriform as it
is about development managers. Those all have their own interest. The best
does often (and especially in the case of persons) not match the personal
interest of those.

The first things you need is in my idea a manager that is above the
development managers and responsible for the best implementation of objects
(entitities) that need to be shared.

Cor


"Greg" <(E-Mail Removed)> wrote in message
news:7C9A6CB9-D4EB-4A78-98EB-(E-Mail Removed)...
>I am hoping someone can shed some light on a current topic of discussion
>with
> all of our development managers.
>
> All of our applications utilize 6 common objects; however we do not have
> Common objects built.
> For example all our applications have a Person object ( name, address(s),
> phone(s), and a collection of attributes specific to the application ).
> These
> “objects” may be a data table, dataset, or class file. Also, each
> application
> has it own database.
>
>
> My question is what would be the best way to architect this so that I am
> not
> creating a copy of a base library project and changing out the DAL for
> each
> application that is built.
>

Greg


I would personally go for a Business Logic aproach before the DAL so

Presentation , BLS , DAL
http://upload.wikimedia.org/wikipedi...pplication.png

This is a proven method with the highest flexibility ,
Also i would constrain the shared entities with interfaces , so you can
never forget to implement them in one of the BLS sub classes

hth

Michel




"Greg" <(E-Mail Removed)> schreef in bericht
news:7C9A6CB9-D4EB-4A78-98EB-(E-Mail Removed)...
>I am hoping someone can shed some light on a current topic of discussion
>with
> all of our development managers.
>
> All of our applications utilize 6 common objects; however we do not have
> Common objects built.
> For example all our applications have a Person object ( name, address(s),
> phone(s), and a collection of attributes specific to the application ).
> These
> "objects" may be a data table, dataset, or class file. Also, each
> application
> has it own database.
>
>
> My question is what would be the best way to architect this so that I am
> not
> creating a copy of a base library project and changing out the DAL for
> each
> application that is built.
>