design question( the app is written in c# ;) )

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

parez - 28 Feb 2008 14:20 GMT

Layer A is on top on Layer B.
Layer A talks to layer B using the interfaces defined in B. For input
and return values.

My question is should i take out the interfaces from B and put it in a
separate project?

Reply to this Message

Cowboy (Gregory A. Beamer) - 28 Feb 2008 15:12 GMT

The extraction of interfaces is most useful if you are going to create a
completely different layer B for other applications. If you are simply going
to version with additional "providers", you can do that in the same library.
It really depends on where you are going with this one.

One time it is a great idea to move out into its own library is a case where
you have multiple clients who each need a slightly different version of the
library, but do not want to ship other client's implementations with the
library. You will generally go to a config driven provider model in this
case, however, so you can test multiple implementations with simple
configuration changes.

Signature

Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************

| Think outside the box!

*************************************************

> Layer A is on top on Layer B.
> Layer A talks to layer B using the interfaces defined in B. For input
> and return values.
>
> My question is should i take out the interfaces from B and put it in a
> separate project?

Reply to this Message

parez - 28 Feb 2008 16:36 GMT

On Feb 28, 10:12 am, "Cowboy \(Gregory A. Beamer\)"
<NoSpamMgbwo...@comcast.netNoSpamM> wrote:

> The extraction of interfaces is most useful if you are going to create a
> completely different layer B for other applications. If you are simply going
[quoted text clipped - 21 lines]
> > My question is should i take out the interfaces from B and put it in a
> > separate project?

I am trying to make component B resusable and also replaceable if need
be.

1)If I use interfaces defined in B then it will make it resusable.
2)If i separate the interfaces in to a different project then it will
make B replacable by a component C which uses the same interafaces..

Correct me if i am wrong.

so 2 should be the way to go.

Reply to this Message

Cowboy (Gregory A. Beamer) - 28 Feb 2008 18:17 GMT

If you want to replace a complete component, then separation will work well.
If you can put things together in a single library, then it need not be (ie,
add classes). Plug and play is certainly easier if interafaces are in a
different project. For deploying, you might still wish to compile the
interface assembly into the other assembly when you get close to deploying.

Signature

Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************

| Think outside the box!

*************************************************

> On Feb 28, 10:12 am, "Cowboy \(Gregory A. Beamer\)"
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
[quoted text clipped - 43 lines]
>
> so 2 should be the way to go.

Reply to this Message

Arne Vajhøj - 29 Feb 2008 04:16 GMT

> On Feb 28, 10:12 am, "Cowboy \(Gregory A. Beamer\)"
> <NoSpamMgbwo...@comcast.netNoSpamM> wrote:
[quoted text clipped - 25 lines]
>
> so 2 should be the way to go.

If you make it the right way then it should not matter much !

The right way means that only the API (interface, factory, pure
data classes) are public and the rest is internal.

Explanation:

public API + internal impl in B

you want a different implementation

public API in B + internal impl #1 + internal impl #2 in B

or

public API in B
public impl #1 in C1
public impl #2 in C2

is invisible to A.

The important aspect is to ensure that A does not use any implementation
specific features.

Arne

Reply to this Message

design question( the app is written in c# ;) )

Free Magazines