Architectural question

[Rowan]

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

 

[Michael Nemtsev]

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

 

[Peter Bradley]

Ysgrifennodd Rowan:

Hi there,

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

 

[Jason Kester]

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/

 

[Kevin Spencer]

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

 

[Mike]

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.

 

[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?

 

[Mike]

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?

 

[Peter Bradley]

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

 

[Rowan]

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

 

[Peter Bradley]

Ysgrifennodd Rowan:

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

Best of luck.

Post again if you need any more help.


Peter

 

[Jason Kester]

Post again if you need any more help.

Yeah, another vote here for multiple projects, and another vote for
good luck too. It's refreshing to see somebody asking for advice here
who has done a bit of homework and put some thought into his
question. This group has been getting way too many "I'm too rushed to
read the documentation. Somebody tell me how to read a text file from
the disk!" type questions.

Keep us posted, and don't hesitate to come back if you need any
additional advice!

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

 

[Rowan]

I didn't think I would be back this quickly. I've been researching
debug/trace/assert and am trying to decide the best approach to take.
I want to get in the habit straight out of the gate. I've read some
articles by John Robbins on the subject and the Superassert he did but
don't think it is quite the right thing to do for the web app.

I work in a department of 2 and so we have no test engineers. We do
the best we can but users are sneaky and come up with all sorts of
ways to do things we would never consider. I think I should put the
asserts into the Windows app that I write later on because we have in
house users who will be working with that app and have become used to
being our "testers". However the web app is a different story...our
customers will be logging onto that and obviously we don't want them
to see any problems. I was thinking I should log asserts to a text
file or leave asserts out altogether and do trace stuff instead. I
realize that the main problem with this idea is if I release it the
debug stuff is supposed to be ignored or not included in the exe. I
am sure there is somewhat of a standard approach to this. Any
suggestions?