Project Dependency and Architecture

[shapper]

Hello,

I am working on an ASP.NET project and it is getting a kind of big.
So I decided to create 3 projects:

Site.Core > Contains common helpers classes, repositories,
interfaces, models, etc
Site.LinqToSqlProvider > Contains the code to communicate with a SQL
database using LinqToSql
(I can have other providers like Site.XML if the data is saved on
XML files instead of using an SQL database)
Site > The site itself

A few questions:

1. Site.Core should be visible to both Site.LinqToSqlProvider and Site
Site.LinqToSqlProvider shoudl be visible to Site

Is there a way to create these dependencies in VS2008?

2. Is this a good approach?

3. Should I name the providers in some other way?

Thanks,
Miguel

 

[Pavel Minaev]

I am working on an ASP.NET project and it is getting a kind of big.
So I decided to create 3 projects:

Site.Core  > Contains common helpers classes, repositories,
interfaces, models, etc
Site.LinqToSqlProvider  >  Contains the code to communicate with a SQL
database using LinqToSql
    (I can have other providers like Site.XML if the data is saved on
XML files instead of using an SQL database)
Site > The site itself

A few questions:

1. Site.Core should be visible to both Site.LinqToSqlProvider and Site
    Site.LinqToSqlProvider shoudl be visible to Site

What do you mean by "visible"? Assemblies are always "visible" to each
other.

If you mean to somehow restrict the visibility of types within
assemblies, then you can do so; you can have them declared "internal",
and then use InternalsVisibleToAttribute to specify other assemblies
which should be able to access them. But this is rarely worth the
bother, and even then mostly for reusable multi-assembly libraries,
not for applications.

2. Is this a good approach?

Probably. I don't see anything wrong with your description, but then
again, it's too high-level to say anything more definite.

3. Should I name the providers in some other way?

Such as? Really, just name them in any way that is 1) descriptive, and
2) consistent. For example, always prefix them with "...Provider". Or
maybe "...DataProvider", since you might have other kinds.

 

[shapper]

What do you mean by "visible"? Assemblies are always "visible" to each
other.

If you mean to somehow restrict the visibility of types within
assemblies, then you can do so; you can have them declared "internal",
and then use InternalsVisibleToAttribute to specify other assemblies
which should be able to access them. But this is rarely worth the
bother, and even then mostly for reusable multi-assembly libraries,
not for applications.

Sorry, I don't know how to explain it well.

What I mean is add some kind of reference in Site to Site.Core so that
I don't need to compile and copy dll's.
I think this can be done ... or not?

Probably. I don't see anything wrong with your description, but then
again, it's too high-level to say anything more definite.

I am thinking in general to ... I am just starting to migrate my old
project to this architecture.
I still have some thicking to do on the details.

Such as? Really, just name them in any way that is 1) descriptive, and
2) consistent. For example, always prefix them with "...Provider". Or
maybe "...DataProvider", since you might have other kinds.

Yes, DataProvider is a good prefix. I will change it.
Thank you for the suggestion.
In fact I saw a Microsoft project and they called it just that.

 

[Pavel Minaev]

What I mean is add some kind of reference in Site to Site.Core so that
I don't need to compile and copy dll's.
I think this can be done ... or not?

Oh, yes, of course. If you're working in Visual Studio, right-click
your project in Solution Explorer and select "Add References". You can
add reference to another project in the same solution, and then it
will be automatically rebuild if and when needed.

 

[shapper]

Oh, yes, of course. If you're working in Visual Studio, right-click
your project in Solution Explorer and select "Add References". You can
add reference to another project in the same solution, and then it
will be automatically rebuild if and when needed.

Ah ok ... I was just creating dependencies by clicking on the
solution.
I thought that dependencies was going to do that ...

So what is dependencies for?

 

[Pavel Minaev]

Ah ok ... I was just creating dependencies by clicking on the
solution.
I thought that dependencies was going to do that ...

So what is dependencies for?

It's hard to say, since I'm not aware of any kind of "dependencies"
that one might be able to add by clicking on the solution in Solution
Explorer. Can you be more precise?

 

[shapper]

It's hard to say, since I'm not aware of any kind of "dependencies"
that one might be able to add by clicking on the solution in Solution
Explorer. Can you be more precise?

Sure,

When you right click on the solution you have the option "Project
Dependencies".
On this window you can select for each project its dependencies (other
solution projects)".
You can also specify the build order.

I though that if I would specify that Site.LinqToSqlProvider dependes
on Site.Core than Site.Core would be "visible" Site.LinqToSqlProvider
but it seems not. I need to add the reference as you told me.

Probably Project Dependencies has only to do with Building
Dependencies ...

You don't have that on your VS? I am using VS Pro 2008 ...

Thank You,
Miguel