Re: VB.net and ASP.Net Typed Datasets

Rick,

In addition to Scott, be aware that the ASPNET architecture is true physical
3 tier while a windowforms is standard a physical 2 tier.

This means that the application you create is the middle tier, which is used
by all your client with the general UI client their browser. This means that
if you have created layers (by instance a DAL or a BLL) which uses shared
(static in C#) Data than that will be used by all clients, this can make
quite a mash of it, if this is by the client updatable data.

Cor

"Rick Vooys" <RickVooys@discussions.microsoft.com> schreef in bericht
news:4863365F-6A07-4CAB-BCB5-17F5D1C4DBC0@microsoft.com...
> Quick background, we are upgrading our old Access Application. We have
> upgraded the "backend" or data layer to SQL Server 2005. Currently we have
> the previous Access frontend linked via ODBC and are working on creating a
> new Frontend. The frontend only needs to be accessed via the company
> intranet, but in the future we would like to open up access for clients to
> view certain data.
>
> For these reasons we wish to use ASP.net, to have a Smart Client.
> Currently
> we have designed a DAL and BLL using typed datasets with the Dataset
> designer.
>
> But as we step through a section of our application, we are noticing VAST
> inadequacies with the web controls and the winform. I.E Combo boxes do not
> exist, the postbacks etc. We have tried some of the AJAX enabled controls
> but
> they do not take away all the issues.
>
> I have a couple questions, and I'm not sure if this the best forum for
> answers to these questions but any help, even which forum would be better
> suited for me is appreciated.
>
> 1. Can we use the typed Datasets we have created with the custom BLL with
> Vb.net. I have yet to see any examples? Can someone point me in the
> direction
> of where the information to do this would be. In theory with a muti-tiered
> application I should be able to keep those layers completely independent
> and
> use either ASP.net or VB.net correct?
>
> 2. Is Microsoft going to take the Atlas/AJAX controls a step further? Or
> is
> there something we can use. I am sure the VB.net controls are much richer
> because they do not depend on the Windows Web form, but I cannot propose
> to
> roll out an application that makes data entry more difficult. Any ideas on
> how to streamline a ASP.net Web application to make it seem more desktop
> based? If I can keep the DAL and BLL the same, writing in VB.net and then
> in
> a year another rewrite is acceptable, but if we need to re-write those
> layers
> as well I will have to look at another plan of attack.
>
> Thanks ahead of time.
>

"Tiers" are nothing more than classes designed to do one particular type of
job.

If you have a class that does just your business logic (or 27 classes that
do nothing but handle business logic), then you have one tier (made up of
however many classes do the work [1 or 27]) that represents your business
layer. If you have other classes that just handle your data access and
manipulation, then that is another tier. Of course, this code needs to be
called from somewhere (either a web client or a Windows Forms app) and so,
that would be your presentation tier, making your 3rd tier.

I do have some questions/concerns about what you wound up with though. See
my responses inline....

"Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
news:E0EF978D-049D-4D23-BEB3-ADDC80222E56@microsoft.com...
> First of all, thanks for all the advice. It really got me moving in the
> right
> direction.
>
> What I have set up is a web service that will contain the buisnees logic,
> it
> returns datasets that we use will ADO.net controls.

Your web service *returns* datasets to the caller of the web service (either
an ASP.NET web form or a Windows Form)? This is generally not considered to
be a good idea for scalability reasons. A DataSet is a .NET (Microsoft)
structure. What if, in the future, you decide to make the front-end of the
application a Java Server Page? The DataSet object won't be recognized in
the J2EE environment. Now, I know what you are saying... "That wouldn't
happen." Well, let me just tell you that the last thing you think will
happen in the future is generally the very next thing that will happen in
the future, really!

The whole point of web services is to create a non-proprietary,
platform-independant remote procedure call via http. If your web service
returns a proprietary result, then doesn't that kind of defeat the purpose
of web services in the first place?

DataSets are fine to use and pass back and forth in the back-end of your
application (i.e. between business and data layers) because that part of
your architecture will likely be all the same. But between the web service
and the presentation layer, you should stay as open as possible, hence the
purpose of web services. Instead of passing a DataSet, you should pass the
XML representation of the DataSet (DataSet.GetXML()) or a different form of
XML alltogether (manually created by the business or data layers).

> It uses the typed Datasets to access the SQL Server database.

DataSets don't *access* any data. They are merely repositories to store
copies of data.

> It can be consumed by either a web application (ASP.net) or with Windows
> forms.

See my first comment about not using DataSets for this.

> We have still not decided
> which route to go with, Web or Windows forms, but the now we have the
> ability
> to mix/match or switch if we need be.

Yes.

> One of the main reasons for the 3 tiered enviroment right.

Yes.

> Now isn't this 3 tier? Cor, could you elaborate on your statement?

See my very first comments at the top of this message. Now, you are going
to love hearing this, but I would suggest adding a 4th tier/layer so that
your business logic is NOT handled directly in the web service, but instead
is handled by separate, non web-service classes and use the web service
class to contact the correct business class. So, the progression would be:

Presentation Layer (Web Form or WinForm) makes a request for the web
service.
Workflow Layer (Web Service) calls appropriate business layer class based on
what the Presentation Layer requested.
Business Layer (stand-alone class) processes business logic.
Data Layer (stand-alone class) is called by business layer when data
access/data manipulation is needed.

By squeezing a 4th layer in there (the Workflow Layer, which is the Web
Service), you gain the ability to swap out business layer logic without
changing the interface that the web service caller must call. The web
service becomes nothing more than a proxy class, a pass-through, a traffic
cop or the doorway to the back-end of your application.

> Can I get what you guys list as the pros/cons for web vs windows forms?

Web Forms (ASP.NET) benefits:

No client installations/updates/patches.
Platform-independent.
Accessible from any location (that has Internet connectivity).

Web Forms (ASP.NET) deficits:

Doesn't usually perform quite as well as client applications (bandwith).
More support usually required (server maintenance, security, etc.)

WinForms benefits:

Performs well.
Rich set of controls and UI components.

WinForms deficits:

Local installations/updates/patches required.
Requires local machine to have correct .NET Framework version.
Not accessible from anywhere/anytime.

> Is is true local file manipulation is a problem from a web application,

Yes.

> wouldn't vb.net or C# have file manipluation (import/export from
> spreadsheets) built in. Or could it be a sercuity issue?

It's not so much an issue for VB.NET or C#, it's a matter of whether this
VB.NET or C# is running client vs. server side. Server-side code can't
manipulate client-side hard drives because the code doesn't execute on the
client, it executes on the server.

Client-side code CAN manipulate the client hard drive (but client security
settings may still prohibit this activity for obvious reasons), but remember
that .NET code is NOT client-side code UNLESS you are building a WinForms
application. You can still do ASP.NET and do client-side file manipulation
but, it wouldn't be the .NET code doing the work, you'd need JavaScript/VB
Script running locally to do this.

>
> "Cor Ligthert [MVP]" wrote:
>
>> This means that the application you create is the middle tier, which is
>> used
>> by all your client with the general UI client their browser. This means
>> that
>> if you have created layers (by instance a DAL or a BLL) which uses shared
>> (static in C#) Data than that will be used by all clients, this can make
>> quite a mash of it, if this is by the client updatable data.
>>
>> Cor
>

Scott, again, mucho thanks for the input. Thanks.

But I am a bit confused with these statements. Again, I am really new to
this and we are just trying to figure out the best architecture with a small
demo so we can convert the entire app, so it is important we don't do
anything we might re-do (as you listed with the java, the other developer I
work with mentioed this as well)

"Scott M." wrote:

> Your web service *returns* datasets to the caller of the web service (either
> an ASP.NET web form or a Windows Form)? This is generally not considered to
> be a good idea for scalability reasons. A DataSet is a .NET (Microsoft)
> structure. What if, in the future, you decide to make the front-end of the
> application a Java Server Page? The DataSet object won't be recognized in
> the J2EE environment. Now, I know what you are saying... "That wouldn't
> happen." Well, let me just tell you that the last thing you think will
> happen in the future is generally the very next thing that will happen in
> the future, really!

> The whole point of web services is to create a non-proprietary,
> platform-independant remote procedure call via http. If your web service
> returns a proprietary result, then doesn't that kind of defeat the purpose
> of web services in the first place?

> DataSets are fine to use and pass back and forth in the back-end of your
> application (i.e. between business and data layers) because that part of
> your architecture will likely be all the same. But between the web service
> and the presentation layer, you should stay as open as possible, hence the
> purpose of web services. Instead of passing a DataSet, you should pass the
> XML representation of the DataSet (DataSet.GetXML()) or a different form of
> XML alltogether (manually created by the business or data layers).

> See my very first comments at the top of this message. Now, you are going
> to love hearing this, but I would suggest adding a 4th tier/layer so that
> your business logic is NOT handled directly in the web service, but instead
> is handled by separate, non web-service classes and use the web service
> class to contact the correct business class. So, the progression would be:

> Presentation Layer (Web Form or WinForm) makes a request for the web
> service.
> Workflow Layer (Web Service) calls appropriate business layer class based on
> what the Presentation Layer requested.
> Business Layer (stand-alone class) processes business logic.
> Data Layer (stand-alone class) is called by business layer when data
> access/data manipulation is needed.

> By squeezing a 4th layer in there (the Workflow Layer, which is the Web
> Service), you gain the ability to swap out business layer logic without
> changing the interface that the web service caller must call. The web
> service becomes nothing more than a proxy class, a pass-through, a traffic
> cop or the doorway to the back-end of your application.

I may have been mispoken when I descibed our Buisness Logic, the other
developer has been building this. It returns a table adapter. So we use the
objectdatasource to "bind" the control to our buisness logic? Is this still
wrong? I guess in the way I see it, don't we need to return some sort of .Net
object so we can bind to these contols?

In regards to your suggestion? Do you have some code examples of this. I
think I get it in theory, but I wouldn't have a clue how to start it.

> I may have been mispoken when I descibed our Buisness Logic, the other
> developer has been building this. It returns a table adapter. So we use
> the
> objectdatasource to "bind" the control to our buisness logic? Is this
> still
> wrong?

Yes, it's still wrong. You don't want to return anything *from* your web
service that is .NET specific (for the scalability reasons I described
earlier). Web Services should return non-proprietary, platform-independent
data. That pretty much means strings and XML. A TableAdapter is a .NET
proprietary class. If you ever decided to call your web service from a
non-.NET application, it wouldn't know what to do with a TableAdapter. Have
your data layer go and get the SQL data and return that to the business
layer so the business layer can perform business logic on the data (if there
is no business logic to perform, in the case of a read only query) then your
business layer is not needed at all (which you can't do right now because
your business layer is your web service and you can't skip the web service).
This is why I recommend making a 4th layer so that the business layer can be
separated from the web service. Anyway, when the data has been retrieved,
get the XML representation of the data (if you had the data in a DataSet,
for example, you could call the GetXML method of the DataSet to get the XML
string that represents the data) and return that XML (not the container that
you got the XML out of). This raw XML can be consumed on any platform by
any programming language.

> I guess in the way I see it, don't we need to return some sort of .Net
> object so we can bind to these contols?

NO! That is exactly what you do NOT want to do. As mentioned above, return
something that can be consumed anywhere. All you'd need to do in your
presentation layer is read that XML back into your .NET object (like a
DataSet) and then you use that as the DataSource for your presentation layer
controls.

> In regards to your suggestion? Do you have some code examples of this. I
> think I get it in theory, but I wouldn't have a clue how to start it.

[pseudo code]

Data Layer:

Public Class DoDataStuff()
Public Sub GetConnected
'Write code that connects to database here
End Sub

Public Function GetAllData() As DataSet
GetConnected()
Dim theDataSet As New DataSet()
'Write code to query the database and store results in a DataSet
here
Return theDataSet
End Function
End Class

Business Layer:

Public Class DoBusinessStuff()
Public Function ManipulateData() As String
'Make an instance of the data layer
Dim dl As New DoDataStuff()
'Have the data layer return data here
Dim resutData As DataSet = dl.GetAllData

'Write code here that applies your business logic to the data

Return resultData.getXML()
End Function
End Class

Workflow Layer:

<WebService> Public Class Workflow
<WebMethod> Public Function GetData() As String
'This method is just a proxy to the business layer
'allowing the interface to the back-end processes to
'be separated from those processes

'If you need the data and have to apply business logic, you'd
write...
Dim bl As New DoBusinessStuff()
Return bl.ManipulateData()

'Or, if you just need the data, but don't need to apply business
rules, you'd write...
Dim dl As New DoDataStuff()
Return dl.GetAllData.getXML()

End Function
End Class

At this point, your presentation layer (whatever it is) can call the
appropriate workflow layer method and either way it will get back an XML
string that represents the data, but NOT a .NET proprietary class that
contains the data (big difference).

Presentation Layer:

....Inside either a web form or a WinForm make your reference to the assembly
that contains the previous code...

Dim wf As New Workflow()
'Call the workflow method that you need...
Dim ds As New DataSet()

'Get the XML string into an object that your presentation controls can bind
to
Dim sr As New System.Text.StringReader(wf.GetData())
ds.ReadXML(sr)

'Bind your presentation controls to the data container...
'For example, assume you've already created a DataGrid control called "dg"
on the form
dg.DataSource = ds
dg.DataBind()

So, in the end, you can see we have 4 layers, each doing a very specific job
and between the Workflow and the Presentation there is only ever
non-proprietary, platform-independant data being passes, which allows for
maximum scalability and fully leverages the purpose of web services in the
first place.

HTH

-Scott

Hey Rick,

Sorry, I don't really have any meaningfull suggestions in this are. I've use
Crystal Reports in the past, but only in limited ways.

Good luck with your project.

-Scott


"Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
news:F6E20E27-8C4C-40CD-A182-F892C6E87EB7@microsoft.com...
> Thanks Scott, makes much more sense to me now.
>
> Just to switch gears on you (And I have no clue which newsgroup to post
> this
> in, so I want your opinion), I am looking for a Reporting Tool. I don't
> know
> if you are familar with the Access one, but something that can accomplish
> all
> that it does, as well can be bound to XML from our Web Service, and easily
> usable from ASP.Net and Windows forms. Any ideas?
>
> The other developer tried SQL Reporting and the intial outcome was not
> good.
> He said it seemed much to simple?
> "Scott M." wrote:
>
>> > I may have been mispoken when I descibed our Buisness Logic, the other
>> > developer has been building this. It returns a table adapter. So we use
>> > the
>> > objectdatasource to "bind" the control to our buisness logic? Is this
>> > still
>> > wrong?
>>
>> Yes, it's still wrong. You don't want to return anything *from* your web
>> service that is .NET specific (for the scalability reasons I described
>> earlier). Web Services should return non-proprietary,
>> platform-independent
>> data. That pretty much means strings and XML. A TableAdapter is a .NET
>> proprietary class. If you ever decided to call your web service from a
>> non-.NET application, it wouldn't know what to do with a TableAdapter.
>> Have
>> your data layer go and get the SQL data and return that to the business
>> layer so the business layer can perform business logic on the data (if
>> there
>> is no business logic to perform, in the case of a read only query) then
>> your
>> business layer is not needed at all (which you can't do right now because
>> your business layer is your web service and you can't skip the web
>> service).
>> This is why I recommend making a 4th layer so that the business layer can
>> be
>> separated from the web service. Anyway, when the data has been
>> retrieved,
>> get the XML representation of the data (if you had the data in a DataSet,
>> for example, you could call the GetXML method of the DataSet to get the
>> XML
>> string that represents the data) and return that XML (not the container
>> that
>> you got the XML out of). This raw XML can be consumed on any platform by
>> any programming language.
>>
>> > I guess in the way I see it, don't we need to return some sort of .Net
>> > object so we can bind to these contols?
>>
>> NO! That is exactly what you do NOT want to do. As mentioned above,
>> return
>> something that can be consumed anywhere. All you'd need to do in your
>> presentation layer is read that XML back into your .NET object (like a
>> DataSet) and then you use that as the DataSource for your presentation
>> layer
>> controls.
>>
>> > In regards to your suggestion? Do you have some code examples of this.
>> > I
>> > think I get it in theory, but I wouldn't have a clue how to start it.
>>
>> [pseudo code]
>>
>> Data Layer:
>>
>> Public Class DoDataStuff()
>> Public Sub GetConnected
>> 'Write code that connects to database here
>> End Sub
>>
>> Public Function GetAllData() As DataSet
>> GetConnected()
>> Dim theDataSet As New DataSet()
>> 'Write code to query the database and store results in a DataSet
>> here
>> Return theDataSet
>> End Function
>> End Class
>>
>> Business Layer:
>>
>> Public Class DoBusinessStuff()
>> Public Function ManipulateData() As String
>> 'Make an instance of the data layer
>> Dim dl As New DoDataStuff()
>> 'Have the data layer return data here
>> Dim resutData As DataSet = dl.GetAllData
>>
>> 'Write code here that applies your business logic to the data
>>
>> Return resultData.getXML()
>> End Function
>> End Class
>>
>> Workflow Layer:
>>
>> <WebService> Public Class Workflow
>> <WebMethod> Public Function GetData() As String
>> 'This method is just a proxy to the business layer
>> 'allowing the interface to the back-end processes to
>> 'be separated from those processes
>>
>> 'If you need the data and have to apply business logic, you'd
>> write...
>> Dim bl As New DoBusinessStuff()
>> Return bl.ManipulateData()
>>
>> 'Or, if you just need the data, but don't need to apply business
>> rules, you'd write...
>> Dim dl As New DoDataStuff()
>> Return dl.GetAllData.getXML()
>>
>> End Function
>> End Class
>>
>> At this point, your presentation layer (whatever it is) can call the
>> appropriate workflow layer method and either way it will get back an XML
>> string that represents the data, but NOT a .NET proprietary class that
>> contains the data (big difference).
>>
>> Presentation Layer:
>>
>> ....Inside either a web form or a WinForm make your reference to the
>> assembly
>> that contains the previous code...
>>
>> Dim wf As New Workflow()
>> 'Call the workflow method that you need...
>> Dim ds As New DataSet()
>>
>> 'Get the XML string into an object that your presentation controls can
>> bind
>> to
>> Dim sr As New System.Text.StringReader(wf.GetData())
>> ds.ReadXML(sr)
>>
>> 'Bind your presentation controls to the data container...
>> 'For example, assume you've already created a DataGrid control called
>> "dg"
>> on the form
>> dg.DataSource = ds
>> dg.DataBind()
>>
>> So, in the end, you can see we have 4 layers, each doing a very specific
>> job
>> and between the Workflow and the Presentation there is only ever
>> non-proprietary, platform-independant data being passes, which allows for
>> maximum scalability and fully leverages the purpose of web services in
>> the
>> first place.
>>
>> HTH
>>
>> -Scott
>>
>>
>>

Scott, This may seem like a dumb question (I know the only dumb questions are
the ones never asked). In a setup like we are discussing, is the buisness
logic processed on the Server or the client. I would say it is all on the
server, even if we are using the Windows forms? Am I correct? If I am, thats
seems like a waste of processing power to me, since one of the reasons we
would want to use Windows forms is to use the powerful desktop PCs.

"Scott M." wrote:

> > I may have been mispoken when I descibed our Buisness Logic, the other
> > developer has been building this. It returns a table adapter. So we use
> > the
> > objectdatasource to "bind" the control to our buisness logic? Is this
> > still
> > wrong?
>
> Yes, it's still wrong. You don't want to return anything *from* your web
> service that is .NET specific (for the scalability reasons I described
> earlier). Web Services should return non-proprietary, platform-independent
> data. That pretty much means strings and XML. A TableAdapter is a .NET
> proprietary class. If you ever decided to call your web service from a
> non-.NET application, it wouldn't know what to do with a TableAdapter. Have
> your data layer go and get the SQL data and return that to the business
> layer so the business layer can perform business logic on the data (if there
> is no business logic to perform, in the case of a read only query) then your
> business layer is not needed at all (which you can't do right now because
> your business layer is your web service and you can't skip the web service).
> This is why I recommend making a 4th layer so that the business layer can be
> separated from the web service. Anyway, when the data has been retrieved,
> get the XML representation of the data (if you had the data in a DataSet,
> for example, you could call the GetXML method of the DataSet to get the XML
> string that represents the data) and return that XML (not the container that
> you got the XML out of). This raw XML can be consumed on any platform by
> any programming language.
>
> > I guess in the way I see it, don't we need to return some sort of .Net
> > object so we can bind to these contols?
>
> NO! That is exactly what you do NOT want to do. As mentioned above, return
> something that can be consumed anywhere. All you'd need to do in your
> presentation layer is read that XML back into your .NET object (like a
> DataSet) and then you use that as the DataSource for your presentation layer
> controls.
>
> > In regards to your suggestion? Do you have some code examples of this. I
> > think I get it in theory, but I wouldn't have a clue how to start it.
>
> [pseudo code]
>
> Data Layer:
>
> Public Class DoDataStuff()
> Public Sub GetConnected
> 'Write code that connects to database here
> End Sub
>
> Public Function GetAllData() As DataSet
> GetConnected()
> Dim theDataSet As New DataSet()
> 'Write code to query the database and store results in a DataSet
> here
> Return theDataSet
> End Function
> End Class
>
> Business Layer:
>
> Public Class DoBusinessStuff()
> Public Function ManipulateData() As String
> 'Make an instance of the data layer
> Dim dl As New DoDataStuff()
> 'Have the data layer return data here
> Dim resutData As DataSet = dl.GetAllData
>
> 'Write code here that applies your business logic to the data
>
> Return resultData.getXML()
> End Function
> End Class
>
> Workflow Layer:
>
> <WebService> Public Class Workflow
> <WebMethod> Public Function GetData() As String
> 'This method is just a proxy to the business layer
> 'allowing the interface to the back-end processes to
> 'be separated from those processes
>
> 'If you need the data and have to apply business logic, you'd
> write...
> Dim bl As New DoBusinessStuff()
> Return bl.ManipulateData()
>
> 'Or, if you just need the data, but don't need to apply business
> rules, you'd write...
> Dim dl As New DoDataStuff()
> Return dl.GetAllData.getXML()
>
> End Function
> End Class
>
> At this point, your presentation layer (whatever it is) can call the
> appropriate workflow layer method and either way it will get back an XML
> string that represents the data, but NOT a .NET proprietary class that
> contains the data (big difference).
>
> Presentation Layer:
>
> ....Inside either a web form or a WinForm make your reference to the assembly
> that contains the previous code...
>
> Dim wf As New Workflow()
> 'Call the workflow method that you need...
> Dim ds As New DataSet()
>
> 'Get the XML string into an object that your presentation controls can bind
> to
> Dim sr As New System.Text.StringReader(wf.GetData())
> ds.ReadXML(sr)
>
> 'Bind your presentation controls to the data container...
> 'For example, assume you've already created a DataGrid control called "dg"
> on the form
> dg.DataSource = ds
> dg.DataBind()
>
> So, in the end, you can see we have 4 layers, each doing a very specific job
> and between the Workflow and the Presentation there is only ever
> non-proprietary, platform-independant data being passes, which allows for
> maximum scalability and fully leverages the purpose of web services in the
> first place.
>
> HTH
>
> -Scott
>
>
>

Hi Rick,

All the layers EXCEPT the presentation layer (the Windows Form or the
RESULTS of the Web Form processing) are processed on the server.

While it's true that the client may be able to handle more of the total load
of the processing, the centralized nature of the server code as well as the
other advantages (scalability, maintenance, etc.) more than make up for it.
For applications that require the best performance, you can load balance
your server architecture to handle volume and server processing.

Also, if you have to access data and that data is located on a server, then
you are going to need most of your processing happening on the server
anyway.

"Rick Vooys" <RickVooys@discussions.microsoft.com> wrote in message
news:41A7ACEA-CA17-48EC-A126-E67119BF0A67@microsoft.com...
> Scott, This may seem like a dumb question (I know the only dumb questions
> are
> the ones never asked). In a setup like we are discussing, is the buisness
> logic processed on the Server or the client. I would say it is all on the
> server, even if we are using the Windows forms? Am I correct? If I am,
> thats
> seems like a waste of processing power to me, since one of the reasons we
> would want to use Windows forms is to use the powerful desktop PCs.
>
> "Scott M." wrote:
>
>> > I may have been mispoken when I descibed our Buisness Logic, the other
>> > developer has been building this. It returns a table adapter. So we use
>> > the
>> > objectdatasource to "bind" the control to our buisness logic? Is this
>> > still
>> > wrong?
>>
>> Yes, it's still wrong. You don't want to return anything *from* your web
>> service that is .NET specific (for the scalability reasons I described
>> earlier). Web Services should return non-proprietary,
>> platform-independent
>> data. That pretty much means strings and XML. A TableAdapter is a .NET
>> proprietary class. If you ever decided to call your web service from a
>> non-.NET application, it wouldn't know what to do with a TableAdapter.
>> Have
>> your data layer go and get the SQL data and return that to the business
>> layer so the business layer can perform business logic on the data (if
>> there
>> is no business logic to perform, in the case of a read only query) then
>> your
>> business layer is not needed at all (which you can't do right now because
>> your business layer is your web service and you can't skip the web
>> service).
>> This is why I recommend making a 4th layer so that the business layer can
>> be
>> separated from the web service. Anyway, when the data has been
>> retrieved,
>> get the XML representation of the data (if you had the data in a DataSet,
>> for example, you could call the GetXML method of the DataSet to get the
>> XML
>> string that represents the data) and return that XML (not the container
>> that
>> you got the XML out of). This raw XML can be consumed on any platform by
>> any programming language.
>>
>> > I guess in the way I see it, don't we need to return some sort of .Net
>> > object so we can bind to these contols?
>>
>> NO! That is exactly what you do NOT want to do. As mentioned above,
>> return
>> something that can be consumed anywhere. All you'd need to do in your
>> presentation layer is read that XML back into your .NET object (like a
>> DataSet) and then you use that as the DataSource for your presentation
>> layer
>> controls.
>>
>> > In regards to your suggestion? Do you have some code examples of this.
>> > I
>> > think I get it in theory, but I wouldn't have a clue how to start it.
>>
>> [pseudo code]
>>
>> Data Layer:
>>
>> Public Class DoDataStuff()
>> Public Sub GetConnected
>> 'Write code that connects to database here
>> End Sub
>>
>> Public Function GetAllData() As DataSet
>> GetConnected()
>> Dim theDataSet As New DataSet()
>> 'Write code to query the database and store results in a DataSet
>> here
>> Return theDataSet
>> End Function
>> End Class
>>
>> Business Layer:
>>
>> Public Class DoBusinessStuff()
>> Public Function ManipulateData() As String
>> 'Make an instance of the data layer
>> Dim dl As New DoDataStuff()
>> 'Have the data layer return data here
>> Dim resutData As DataSet = dl.GetAllData
>>
>> 'Write code here that applies your business logic to the data
>>
>> Return resultData.getXML()
>> End Function
>> End Class
>>
>> Workflow Layer:
>>
>> <WebService> Public Class Workflow
>> <WebMethod> Public Function GetData() As String
>> 'This method is just a proxy to the business layer
>> 'allowing the interface to the back-end processes to
>> 'be separated from those processes
>>
>> 'If you need the data and have to apply business logic, you'd
>> write...
>> Dim bl As New DoBusinessStuff()
>> Return bl.ManipulateData()
>>
>> 'Or, if you just need the data, but don't need to apply business
>> rules, you'd write...
>> Dim dl As New DoDataStuff()
>> Return dl.GetAllData.getXML()
>>
>> End Function
>> End Class
>>
>> At this point, your presentation layer (whatever it is) can call the
>> appropriate workflow layer method and either way it will get back an XML
>> string that represents the data, but NOT a .NET proprietary class that
>> contains the data (big difference).
>>
>> Presentation Layer:
>>
>> ....Inside either a web form or a WinForm make your reference to the
>> assembly
>> that contains the previous code...
>>
>> Dim wf As New Workflow()
>> 'Call the workflow method that you need...
>> Dim ds As New DataSet()
>>
>> 'Get the XML string into an object that your presentation controls can
>> bind
>> to
>> Dim sr As New System.Text.StringReader(wf.GetData())
>> ds.ReadXML(sr)
>>
>> 'Bind your presentation controls to the data container...
>> 'For example, assume you've already created a DataGrid control called
>> "dg"
>> on the form
>> dg.DataSource = ds
>> dg.DataBind()
>>
>> So, in the end, you can see we have 4 layers, each doing a very specific
>> job
>> and between the Workflow and the Presentation there is only ever
>> non-proprietary, platform-independant data being passes, which allows for
>> maximum scalability and fully leverages the purpose of web services in
>> the
>> first place.
>>
>> HTH
>>
>> -Scott
>>
>>
>>

Rick,

In my opinion has Scott (and I dont know it anymore I thought me as well)
already that pointed out to you, however Scott gave you an alternative
solution based on your wishes.

Cor

"Rick Vooys" <RickVooys@discussions.microsoft.com> schreef in bericht
news:41A7ACEA-CA17-48EC-A126-E67119BF0A67@microsoft.com...
> Scott, This may seem like a dumb question (I know the only dumb questions
> are
> the ones never asked). In a setup like we are discussing, is the buisness
> logic processed on the Server or the client. I would say it is all on the
> server, even if we are using the Windows forms? Am I correct? If I am,
> thats
> seems like a waste of processing power to me, since one of the reasons we
> would want to use Windows forms is to use the powerful desktop PCs.
>
> "Scott M." wrote:
>
>> > I may have been mispoken when I descibed our Buisness Logic, the other
>> > developer has been building this. It returns a table adapter. So we use
>> > the
>> > objectdatasource to "bind" the control to our buisness logic? Is this
>> > still
>> > wrong?
>>
>> Yes, it's still wrong. You don't want to return anything *from* your web
>> service that is .NET specific (for the scalability reasons I described
>> earlier). Web Services should return non-proprietary,
>> platform-independent
>> data. That pretty much means strings and XML. A TableAdapter is a .NET
>> proprietary class. If you ever decided to call your web service from a
>> non-.NET application, it wouldn't know what to do with a TableAdapter.
>> Have
>> your data layer go and get the SQL data and return that to the business
>> layer so the business layer can perform business logic on the data (if
>> there
>> is no business logic to perform, in the case of a read only query) then
>> your
>> business layer is not needed at all (which you can't do right now because
>> your business layer is your web service and you can't skip the web
>> service).
>> This is why I recommend making a 4th layer so that the business layer can
>> be
>> separated from the web service. Anyway, when the data has been
>> retrieved,
>> get the XML representation of the data (if you had the data in a DataSet,
>> for example, you could call the GetXML method of the DataSet to get the
>> XML
>> string that represents the data) and return that XML (not the container
>> that
>> you got the XML out of). This raw XML can be consumed on any platform by
>> any programming language.
>>
>> > I guess in the way I see it, don't we need to return some sort of .Net
>> > object so we can bind to these contols?
>>
>> NO! That is exactly what you do NOT want to do. As mentioned above,
>> return
>> something that can be consumed anywhere. All you'd need to do in your
>> presentation layer is read that XML back into your .NET object (like a
>> DataSet) and then you use that as the DataSource for your presentation
>> layer
>> controls.
>>
>> > In regards to your suggestion? Do you have some code examples of this.
>> > I
>> > think I get it in theory, but I wouldn't have a clue how to start it.
>>
>> [pseudo code]
>>
>> Data Layer:
>>
>> Public Class DoDataStuff()
>> Public Sub GetConnected
>> 'Write code that connects to database here
>> End Sub
>>
>> Public Function GetAllData() As DataSet
>> GetConnected()
>> Dim theDataSet As New DataSet()
>> 'Write code to query the database and store results in a DataSet
>> here
>> Return theDataSet
>> End Function
>> End Class
>>
>> Business Layer:
>>
>> Public Class DoBusinessStuff()
>> Public Function ManipulateData() As String
>> 'Make an instance of the data layer
>> Dim dl As New DoDataStuff()
>> 'Have the data layer return data here
>> Dim resutData As DataSet = dl.GetAllData
>>
>> 'Write code here that applies your business logic to the data
>>
>> Return resultData.getXML()
>> End Function
>> End Class
>>
>> Workflow Layer:
>>
>> <WebService> Public Class Workflow
>> <WebMethod> Public Function GetData() As String
>> 'This method is just a proxy to the business layer
>> 'allowing the interface to the back-end processes to
>> 'be separated from those processes
>>
>> 'If you need the data and have to apply business logic, you'd
>> write...
>> Dim bl As New DoBusinessStuff()
>> Return bl.ManipulateData()
>>
>> 'Or, if you just need the data, but don't need to apply business
>> rules, you'd write...
>> Dim dl As New DoDataStuff()
>> Return dl.GetAllData.getXML()
>>
>> End Function
>> End Class
>>
>> At this point, your presentation layer (whatever it is) can call the
>> appropriate workflow layer method and either way it will get back an XML
>> string that represents the data, but NOT a .NET proprietary class that
>> contains the data (big difference).
>>
>> Presentation Layer:
>>
>> ....Inside either a web form or a WinForm make your reference to the
>> assembly
>> that contains the previous code...
>>
>> Dim wf As New Workflow()
>> 'Call the workflow method that you need...
>> Dim ds As New DataSet()
>>
>> 'Get the XML string into an object that your presentation controls can
>> bind
>> to
>> Dim sr As New System.Text.StringReader(wf.GetData())
>> ds.ReadXML(sr)
>>
>> 'Bind your presentation controls to the data container...
>> 'For example, assume you've already created a DataGrid control called
>> "dg"
>> on the form
>> dg.DataSource = ds
>> dg.DataBind()
>>
>> So, in the end, you can see we have 4 layers, each doing a very specific
>> job
>> and between the Workflow and the Presentation there is only ever
>> non-proprietary, platform-independant data being passes, which allows for
>> maximum scalability and fully leverages the purpose of web services in
>> the
>> first place.
>>
>> HTH
>>
>> -Scott
>>
>>
>>