Hi there,

I am just starting in .net 2.0 with a background in VB6. I have two
projects to complete. The first being a website and the second is a
client application. For now the majority of the website functionality
will be report access however there will be some insert/update
functionality. In the future the website will perform the same
functions as the client app though the interfaces will need to be
different.

I've constructed the architecture with a Data Access Layer, a Business
Logic Layer, and the Presentation Layer. But as I am thinking about
future use I think it makes sense to put the DAL and BLL in a web
service and then simply create my two projects each as a Presentation
Layer that consume this service. If I do this would I also need
another Data Layer in my website for ad hoc queries that may come up
or for work that is web function specific?

I am uncertain if this truly is the best approach since I have no
experience to base judgement. Is there a better way to do this?
Would a web service slow user processing down at all? Would I put the
two layers in the same web service or should I keep the BLL in the
website and build another for the client app or some other variation?
I have read many articles on this and have stepped through tutorials
but would really like an experienced take on it before I move
forward. Help is greatly appreciated.

Rowan

Hello Rowan,

R> I've constructed the architecture with a Data Access Layer, a
R> Business Logic Layer, and the Presentation Layer. But as I am
R> thinking about future use I think it makes sense to put the DAL and
R> BLL in a web service and then simply create my two projects each as a
R> Presentation Layer that consume this service.

Only put WS *upon* the BLL & DAL layers, it untied your dependecies and your
can change the WS easily

R> If I do this would I also need another Data Layer in my website for ad
hoc queries that
R> may come up or for work that is web function specific?

Why? Let's expose difference service contracs which will be used different
clients, and keep the logic the same
You WS should play like "facade" class

R> I am uncertain if this truly is the best approach since I have no
R> experience to base judgement. Is there a better way to do this?
R> Would a web service slow user processing down at all? Would I put
R> the two layers in the same web service or should I keep the BLL in the
R> website and build another for the client app or some other variation?

Try to simplyfy as much as possible, without any changes to BLL



---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

Ysgrifennodd Rowan:
> Hi there,
>
<snip />
>
> I've constructed the architecture with a Data Access Layer, a Business
> Logic Layer, and the Presentation Layer. But as I am thinking about
> future use I think it makes sense to put the DAL and BLL in a web
> service and then simply create my two projects each as a Presentation
> Layer that consume this service. If I do this would I also need
> another Data Layer in my website for ad hoc queries that may come up
> or for work that is web function specific?
</snip>

On your general point, I think it's generally accepted these days that
an n-Tier approach is a good idea. At the very least, as you suggest,
it allows you to hook up different UI layers to the same back end code.

I'm not sure, though, why you talk about more than one DAL/BLL. You may
need many objects in your data layer, as indeed you might in your
business logic layer; but this is not the same as saying that you have
more than one data access layer/business logic layer. What objects you
need to create and use will, of course, depend on the application model
you develop during the analysis phase of your project.

As for experience in this sort of thing, we don't have any experience of
implementing business logic and data access layers as web services. We
use .NET remoting, using SAOs over TCP/IP. Our primary motivation for
this was to get anything other than presentation layer processing off
the Web server and onto an application server. This has allowed us to
build quite a secure architecture with the web server isolated from our
Windows domain calling a business layer and data access layer which is
on the domain and can therefore use Windows-based security to access the
data - obviating the need to store database credentials anywhere.

Our presentation layer only ever talks to business layer objects: never
DAL objects. These latter are always accessed from the business logic
layer, thus further isolating the public-facing (which includes
"internal only") Web servers from our business data.

You'll have to consider security if you're going to use Web services, to
make sure that the WS is only ever called from your UI components (and
not from some random Web browser with access to the Web server). This
will be particularly important if you add data manipulation facilities
to your application.

And I imagine I don't have to say anything about the dangers of SQL
injection in reporting applications...

HTH


Peter

Why do you want to introduce Web Services into the mix? Everything
you said up to that point made sense. Cramming ALL your data access
through a web service sounds like a terrible idea unless you have some
overwhelming factor forcing your hand that you haven't told us about.
It can only cause pain and bring your performance to a crawl.

My suspicion is that you've read one too many MSDN articles. I'd
stick with your well designed business and data layers. Having done
that, you're well ahead of most .NET applications in terms of
architecture. I bet you'll do well!


Jason Kester
Expat Software Consulting Services
http://www.expatsoftware.com/

---
Get your own Travel Blog, with itinerary maps and photos!
http://www.blogabond.com/

Your idea to use the same back-end for both apps is a good one. Whether to
use a Web Service or not is the problem. First, there are performance
considerations. A Web Service is definitely slow. If you use a Web Service,
you're basically exposing your web service to the Internet, so security must
be considered as well. While using authentication and HTTPS, this can be
overcome. But, let's back up a bit. If you're using a Web Service to access
a database, which I assume is a database server, why not access it directly,
since you're going over the network anyway, and you can have secure database
server access, with less performance issues. Second, putting your BLL into
the Service is unnecessary. Put it into a class library which can be used by
both applications. That will yield the best performance. Remember that the
UI is the only difference here.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net


"Rowan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi there,
>
> I am just starting in .net 2.0 with a background in VB6. I have two
> projects to complete. The first being a website and the second is a
> client application. For now the majority of the website functionality
> will be report access however there will be some insert/update
> functionality. In the future the website will perform the same
> functions as the client app though the interfaces will need to be
> different.
>
> I've constructed the architecture with a Data Access Layer, a Business
> Logic Layer, and the Presentation Layer. But as I am thinking about
> future use I think it makes sense to put the DAL and BLL in a web
> service and then simply create my two projects each as a Presentation
> Layer that consume this service. If I do this would I also need
> another Data Layer in my website for ad hoc queries that may come up
> or for work that is web function specific?
>
> I am uncertain if this truly is the best approach since I have no
> experience to base judgement. Is there a better way to do this?
> Would a web service slow user processing down at all? Would I put the
> two layers in the same web service or should I keep the BLL in the
> website and build another for the client app or some other variation?
> I have read many articles on this and have stepped through tutorials
> but would really like an experienced take on it before I move
> forward. Help is greatly appreciated.
>
> Rowan
>

I agree, your idea made abosolute sense until the web service was mentioned.
I currently have a web app and a client app doing much of the same work,
(showing data, inserts, updates, etc) and they're using the same DL and BAL
without the use of a web service. In my opinion I would only use a web
service if your exchanging data with an outside source, but for apps being
used internally I see no logic in using a web service for a business layer
or data layer. Just create a Class to use with both.

Just my thought.

"Kevin Spencer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Your idea to use the same back-end for both apps is a good one. Whether to
> use a Web Service or not is the problem. First, there are performance
> considerations. A Web Service is definitely slow. If you use a Web
> Service, you're basically exposing your web service to the Internet, so
> security must be considered as well. While using authentication and HTTPS,
> this can be overcome. But, let's back up a bit. If you're using a Web
> Service to access a database, which I assume is a database server, why not
> access it directly, since you're going over the network anyway, and you
> can have secure database server access, with less performance issues.
> Second, putting your BLL into the Service is unnecessary. Put it into a
> class library which can be used by both applications. That will yield the
> best performance. Remember that the UI is the only difference here.
>
> --
> HTH,
>
> Kevin Spencer
> Microsoft MVP
>
> Printing Components, Email Components,
> FTP Client Classes, Enhanced Data Controls, much more.
> DSI PrintManager, Miradyne Component Libraries:
> http://www.miradyne.net
>
>
> "Rowan" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> Hi there,
>>
>> I am just starting in .net 2.0 with a background in VB6. I have two
>> projects to complete. The first being a website and the second is a
>> client application. For now the majority of the website functionality
>> will be report access however there will be some insert/update
>> functionality. In the future the website will perform the same
>> functions as the client app though the interfaces will need to be
>> different.
>>
>> I've constructed the architecture with a Data Access Layer, a Business
>> Logic Layer, and the Presentation Layer. But as I am thinking about
>> future use I think it makes sense to put the DAL and BLL in a web
>> service and then simply create my two projects each as a Presentation
>> Layer that consume this service. If I do this would I also need
>> another Data Layer in my website for ad hoc queries that may come up
>> or for work that is web function specific?
>>
>> I am uncertain if this truly is the best approach since I have no
>> experience to base judgement. Is there a better way to do this?
>> Would a web service slow user processing down at all? Would I put the
>> two layers in the same web service or should I keep the BLL in the
>> website and build another for the client app or some other variation?
>> I have read many articles on this and have stepped through tutorials
>> but would really like an experienced take on it before I move
>> forward. Help is greatly appreciated.
>>
>> Rowan
>>
>
>

I admit I have read quite a few MSDN articles. I also read articles
from other sites which raised doubts in my mind about using WS. That
is why I decided to post a question about it. I haven't felt
comfortable moving forward without knowing for certain why I would or
would not use WS. Glad I verified my doubts. Your answers were all
exactly what I was looking for. It does not make sense to use WS for
this scenario. I have one more question though.

This may seem like a silly question but it is the last thing I need to
know before I can comfortably dive in. To create the back-end BLL and
DAL do I build them in a separate project and compile them into a dll
and use the dll in the client app and web app? What is the common
approach?

Thats what I do.

I create a separate project (class library) and create my BL and DAL in
that, compile it into a DLL then add a reference to that DLL in my projects
that will be using.

I also do this from habit. When I create my BL and DAL project, I add that
project to whatever project I'm working on so if I need to make any changes
to the BL/DAL project I have 1 IDE opened up and the DLL autorefreshs as
well.

make sense?


"Rowan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I admit I have read quite a few MSDN articles. I also read articles
> from other sites which raised doubts in my mind about using WS. That
> is why I decided to post a question about it. I haven't felt
> comfortable moving forward without knowing for certain why I would or
> would not use WS. Glad I verified my doubts. Your answers were all
> exactly what I was looking for. It does not make sense to use WS for
> this scenario. I have one more question though.
>
> This may seem like a silly question but it is the last thing I need to
> know before I can comfortably dive in. To create the back-end BLL and
> DAL do I build them in a separate project and compile them into a dll
> and use the dll in the client app and web app? What is the common
> approach?
>

Ysgrifennodd Rowan:

> This may seem like a silly question but it is the last thing I need to
> know before I can comfortably dive in. To create the back-end BLL and
> DAL do I build them in a separate project and compile them into a dll
> and use the dll in the client app and web app? What is the common
> approach?
>

I'd create two additional projects - one for the DAL and one for the
BLL. It's pretty much a matter of taste, though, I think: but I'd
prefer to see two separate assemblies.

I'd also call the DAL through the BLL, and call the BLL via an
interface; and have the BLL inherit from MarshalByRefObject and
implement the interface. This will allow you to use remoting at a later
date, should you want to.

This may, however, be total overkill for what you have in mind.

It's only my 2c, as well. There'll be plenty of ways of doing this that
I'd never thought of; most will be equally valid and some probably
better than anything I might suggest.

HTH


Peter

It makes perfect sense. I appreciate everyone's help. I feel
comfortable with the design and will dive in now.