Advice needed - splitting up my solution...

[M O J O]

Hi,

I'm creating an CRM solution for my company.

I want to split up the solution into several classlibraries, so I dont need
to build the entire solution every time I run my project.

First I thought about splitting my application up into these libraries:

Solution (solution)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)

Then I thought about reversing it like....

Solution (solution)
Customer (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Contacts (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Documents (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Mails (class library project)
Business (classes)
Presentation (classes)
Data (classes)

And then there's all this redundance to keep in mind.

How would you do it and why??

Is there some kind of best-practice? .... examples??

Thanks!!!

M O J O

[Andrew Faust]

"M O J O" <mojo@_no_spam_delete_this_newwebsolutions.dk> wrote in
message news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi,

I'm creating an CRM solution for my company.

I want to split up the solution into several classlibraries, so
I dont need to build the entire solution every time I run my
project.

First I thought about splitting my application up into these
libraries:

Solution (solution)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)

Then I thought about reversing it like....

Solution (solution)
Customer (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Contacts (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Documents (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Mails (class library project)
Business (classes)
Presentation (classes)
Data (classes)

And then there's all this redundance to keep in mind.

How would you do it and why??

Is there some kind of best-practice? .... examples??

I wouldn't use either of these models. Instead I would do this:

Business (Class Lib)
Presentation (Class Lib)
Data (Class Lib)

<Data Object Class Lib>
Customer
Contacts
Documents
Mails
</Data Object Class Lib>

I would create the Customer, Contacts, Documents and Mails
classes in a seperate library. These classes should be written so
that they can be used generically. Then you can easily just have
your other three classes work on these classes. This not only
helps you reduce duplicate code, but it will allow you to make
changes in your app easier later on.

Andrew Faust

[Kevin Yu [MSFT]]

Thanks for Andrew's quick response!

Hi MOJO,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need some suggestions on your CRM
project. If there is any misunderstanding, please feel free to let me know.

I used to develop CRM systems. Our architecture is just like the following:

Solution (solution)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
General Data Access classes

The data access tier is a general tier, whose methods can be used by all
modules in the business logic tier. Because all the data access operations
are no more than select, insert, update and delete. We have some ready-made
application blocks for data access tier. For example: Data Access
Application Block for .NET from Micrsoft. It can be downloaded from the
following link:

http://msdn.microsoft.com/library/de...us/dnbda/html/
daab-rm.asp

The advantages for putting all modules together, is that we can enforce the
relationship of all the modules. For instance, we can easily get all the
contact names of a certain customer in business logic layer. And we can
also change presentation (like change winform to webform) just by changing
a certain DLL.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[M O J O]

Hi Andrew,

Thank you for giving me some input!!!

The "Data Object Class Lib" - isn't it supposed to be the business layer?

Thanks again.

M O J O

"Andrew Faust" <afaust@aradymeDOTcom> skrev i en meddelelse
news:uA**************@TK2MSFTNGP11.phx.gbl...

"M O J O" <mojo@_no_spam_delete_this_newwebsolutions.dk> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi,

I'm creating an CRM solution for my company.

I want to split up the solution into several classlibraries, so I dont
need to build the entire solution every time I run my project.

First I thought about splitting my application up into these libraries:

Solution (solution)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)

Then I thought about reversing it like....

Solution (solution)
Customer (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Contacts (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Documents (class library project)
Business (classes)
Presentation (classes)
Data (classes)
Mails (class library project)
Business (classes)
Presentation (classes)
Data (classes)

And then there's all this redundance to keep in mind.

How would you do it and why??

Is there some kind of best-practice? .... examples??

I wouldn't use either of these models. Instead I would do this:

Business (Class Lib)
Presentation (Class Lib)
Data (Class Lib)

<Data Object Class Lib>
Customer
Contacts
Documents
Mails
</Data Object Class Lib>

I would create the Customer, Contacts, Documents and Mails classes in a
seperate library. These classes should be written so that they can be used
generically. Then you can easily just have your other three classes work
on these classes. This not only helps you reduce duplicate code, but it
will allow you to make changes in your app easier later on.

Andrew Faust

[M O J O]

Hi Kevin,

Thanks for helping me out here!

I'm a little confused here. You write "General Data Access Classes".
Shouldn't there forexample be a customer class in the data layer or is the
data layer only helper classes??

Correct me if I'm wrong .... I would like to create a new customer. The
presentation layer holds the forms and controls. The presentation layer
tells the business layers customer to create a new customer. The business
layer telsl the data layer the new customer values (fields). The data layer
creates the customer.

Aren't there some good vb.net 3tier examples "out there"? :o)

Thanks again.

M O J O

Ok ... if I want to create a new customer, my presentation layer should fill
in the business layer, which should
"Kevin Yu [MSFT]" <v-****@online.microsoft.com> skrev i en meddelelse
news:n0**************@cpmsftngxa06.phx.gbl...

Thanks for Andrew's quick response!

Hi MOJO,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need some suggestions on your CRM
project. If there is any misunderstanding, please feel free to let me
know.

I used to develop CRM systems. Our architecture is just like the
following:

Solution (solution)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
General Data Access classes

The data access tier is a general tier, whose methods can be used by all
modules in the business logic tier. Because all the data access operations
are no more than select, insert, update and delete. We have some
ready-made
application blocks for data access tier. For example: Data Access
Application Block for .NET from Micrsoft. It can be downloaded from the
following link:

http://msdn.microsoft.com/library/de...us/dnbda/html/
daab-rm.asp

The advantages for putting all modules together, is that we can enforce
the
relationship of all the modules. For instance, we can easily get all the
contact names of a certain customer in business logic layer. And we can
also change presentation (like change winform to webform) just by changing
a certain DLL.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[M O J O]

Hi again,

Is it ok for the presentation layer to use the data layer or should all data
communication go between the business layer and the data layer?

M O J O

"Kevin Yu [MSFT]" <v-****@online.microsoft.com> skrev i en meddelelse
news:n0**************@cpmsftngxa06.phx.gbl...

Thanks for Andrew's quick response!

Hi MOJO,

First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need some suggestions on your CRM
project. If there is any misunderstanding, please feel free to let me
know.

I used to develop CRM systems. Our architecture is just like the
following:

Solution (solution)
CRM.Presentation (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Business (class library project)
Customer (classes)
Contacts (classes)
Documents (classes)
Mails (classes)
CRM.Data (class library project)
General Data Access classes

The data access tier is a general tier, whose methods can be used by all
modules in the business logic tier. Because all the data access operations
are no more than select, insert, update and delete. We have some
ready-made
application blocks for data access tier. For example: Data Access
Application Block for .NET from Micrsoft. It can be downloaded from the
following link:

http://msdn.microsoft.com/library/de...us/dnbda/html/
daab-rm.asp

The advantages for putting all modules together, is that we can enforce
the
relationship of all the modules. For instance, we can easily get all the
contact names of a certain customer in business logic layer. And we can
also change presentation (like change winform to webform) just by changing
a certain DLL.

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi MOJO,

Your understanding is correct. But we have to keep all tiers independent to
each other. So we have to prevent from mixing the business logic tier
things to the data access tier. Also, calling data access methods from
presentation tier has to be avoided. Thus, when we need to change some
features of the application, for example, I need to use an Oracle database
instead of SQL server, we just need to change a single tier. Other tiers
will not be affected and works fine as usual.

Here is an article about the architecture of Duwamish. It is a good example
in MSDN.
http://msdn.microsoft.com/library/de...us/dwamish7/ht
ml/vtoriArchitecturalOverview.asp

You can also check Pet Shop. It's also a good sample.
http://msdn.microsoft.com/library/de...us/dnbda/html/
petshop3x.asp

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[M O J O]

Hi Kevin,

Thank you for your examples. Duwamish seams to be doing what I'm looking
for.

Thanks again!

M O J O
"Kevin Yu [MSFT]" <v-****@online.microsoft.com> skrev i en meddelelse
news:9r**************@cpmsftngxa06.phx.gbl...

Hi MOJO,

Your understanding is correct. But we have to keep all tiers independent
to
each other. So we have to prevent from mixing the business logic tier
things to the data access tier. Also, calling data access methods from
presentation tier has to be avoided. Thus, when we need to change some
features of the application, for example, I need to use an Oracle database
instead of SQL server, we just need to change a single tier. Other tiers
will not be affected and works fine as usual.

Here is an article about the architecture of Duwamish. It is a good
example
in MSDN.
http://msdn.microsoft.com/library/de...us/dwamish7/ht
ml/vtoriArchitecturalOverview.asp

You can also check Pet Shop. It's also a good sample.
http://msdn.microsoft.com/library/de...us/dnbda/html/
petshop3x.asp

HTH.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi MOJO,

You're welcome. Thanks for sharing your experience with all the people
here. If you have any questions, please feel free to post them in the
community.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."