Need advise on application architecture

[Versteijn]

Hello all

I am working on a large enterprise webapplication using VB.NET with an
SQL Server 2000 database. There will be a lot of business logic and
there currently are a lot of tables and data.

For what I have read, strongly typed datasets are the way to go in
this situation, since lots of my data needs to be bound to data aware
controls and that guarantees the simplest/safest way around the
concurreny problems I will be in.

Now, how do I go from there? Should I create a stronly typed dataset
for every table in the database? Or first create logical groups of
data, in the way they will be used in my domain, using views?
In the second case, how are relations kept by the datasets/classes? In
a 1:n situation, does the 1 side contain a collection of objects of
the n side? Or how is this done?

Or should I entirely wrap the generated strongly typed datasets with a
separate business logic layer? I read about it, but find that strange
because the data (which it's all about here) is hidden and can no
longer be bound easy to a datagrid for example. Also, there is room in
the generated strongly typed datasets to contain business logic. But I
guess that's only useful when the classes are not directly based on
the databasestructure (1 class for every table).

Any advise would be very appreciated.

Thank you in advance

Freek Versteijn

 

[Gavin Joyce]

Hi,

You will probably create both single and multi-table strongly-typed
DataSets. As you say, the multi-tabled datasets will have relationships
defined. For example:

Lets say we have a simple database that handles our Customers and their
Orders. Each Customer can have many Orders. We could have three DataSets:

CustomerDataSet
OrderDataSet
CustomerOrderDataSet (Two tables and a one-to-many relationship)

When we want a Customer's details and their Orders, we would fill the
DataSet as follows:

myCustomerOrdersDS = new CustomerOrderBR().GetByCustomerID(3422);

We can now bind this DataSet to controls or navigate through it using the
GetChildRows() method of the Customer DataTable.

Take a look as the sample ASP.NET app at
http://www.ntiergen.net/samples/contacts.

This application uses the above pattern and was generated by my tool
nTierGen.NET - http://www.nTierGen.NET/. This tool generates multiple layers
of code including stored procedures, data access layer, business rules
layer, web services, strongly-typed DataSet (both single and multi-tabled).

I hope this helps,
Gavin Joyce
www.gavinjoyce.com

 

[Versteijn]

Typed datasets also ensure at compile time that you don't try to stick
a date into a string or numeric column. Beyond that, datasets
guarantee nothing (except a bloated executable) and certainly won't
help solve any concurrency problems.

They certainly don't solve concurrency problems, but I think they can
make it easier to tackle these problems instead of having to do all
this yourself in e.g. a datamapper.

Check out the following book:

Expert On-on-One
Visual Basic .NET Business Objects
by Lhotka Rockford

The book came out too late for me to use his framework in my project
but it affirmed my decision to use untyped datasets.

In short, what does the book suggest?

Sincerely

Freek Versteijn

 

[Versteijn]

Or should I entirely wrap the generated strongly typed datasets with a

separate business logic layer? I read about it, but find that strange
because the data (which it's all about here) is hidden and can no
longer be bound easy to a datagrid for example. Also, there is room in
the generated strongly typed datasets to contain business logic. But I
guess that's only useful when the classes are not directly based on
the databasestructure (1 class for every table).

This important part of my message is still unanswered. I really don't
understand whether I should use the generated typed datasets as BLL
object, or wrap them in a datalayer and let the BLL objects access
them or something like that.

See above.

Anyone has a idea? Are there example ntier projects in .NET online?
That would be great to use as a reference.

Thank you

Freek Versteijn

 

[Michael Lang]

Did you see my message? 7/29/03, 11:19AM? I explained the whole three tier
architecture and how to implement it, directly in response to your question.
I even gave a web link to where you can download a sample.

I do recommend a separate business layer, and yes more than DataSets and
DataTables can be bound to data aware controls (such as DataGrid). Take a
look at these controls. The help says anything implementing IList can be
bound to them. CollectionBase implements IList, and can be bound to the
controls. So your collections in the business layer can be bound to the
controls. The data is not "hidden", it is in the business layer but in a
different format. The database itself is all that i hidden from the UI.

I know this method works, as does the dbobjecter code generator. I am the
author (versat1474), and have used it on real projects.

No need for a "strongly typed dataset" even in the datalayer. If you like
them use them, but keep them in your datalayer.

Here is a repost of the original response...
=======================================================================
I also do not use strongly typed datasets. I believe in separating the
layers of the application. The UI should never see a dataset, or anything
from the System.Data namespace. First off I want to much of this content is
my opinion, and not necassarily the best solution. However the enterprise
layered application idea can be found from Microsoft at:
http://msdn.microsoft.com/practices...se/EspPatternsForBuildingEnterpriseSolutions/

First create a data layer (DAL) which contains all your data access code for
each table. It should either call strored procedures or use commands that
use parameter objects for all 4 statements (Select, Update, Delete, Insert).
This layer should know nothing about the business or UI layers. Handling
concurrency issues and overall data integrity (such as by using
transactions) is the responsibility of this layer.

Next create a business logic layer (BLL). It contains the logic to make
sure valid businness data is entered. Such as proper tax rates, shipping
calculations, other accounting and related calculations. I typically create
a class for each table such as "Employee", or "Order" which contain
properties for each table field. Much of your business logic will be in the
property set statements. You can also have methods in these classes that do
business related tasks on those objects. Such as an AddItem method on an
Order class that creates an OrderItem linked to that Order. Also create a
collection for each table containing each instance of the appropriate class.
For example an OrderCollection class containing all orders, or all orders
for a given customer. This collection should be inherited from
CollectionBase so it can be bound to controls in the UI. However, the BLL
should not have any code that references anything in the UI layer. The BLL
will have a reference to the DAL. It is responsible for calling the
approprate Insert ,Update, and Delete methods in the DAL either as changes
are made or when changes are commited. You may also have a rollback
command, which basically empties and refills each collection from the data
layer. It must also create objects in each collection using your Select
commands in the DAL. Therefore the BLL will know about System.Data so it
can work with DataTable and DataRow objects. Each business object should be
able to Fill itself from a DataRow object, and each collection from a
DataTable object.

Lastly create the user interface (UI). It will reference the BLL, but not
the DAL. Each form should bind it's controls to the collections in the BLL.
For the DataGrid you may want to use DataGridTableStyles to show the BLL
data in a custom manner, maybe exclude some properties from the grid? Each
edit in a data bound control will call the set of the appropriate property
in the BLL class which runs your business logic code. The after the set is
complete the get is called to get the validated value and the grid cell is
updated automatically. So the UI code can be really simple. All the UI code
pertains to visual aspects, none of it contains any kind of business logic.

The UI will be responsible for defining the database connection information.
You wouldn't want to hard code that into the DAL. The user or administrator
may need to change connection information at some point. So you will need a
mechanism to pass connection information from the UI settings to the BLL
which passes it to the DAL.

I demonstrate how to do most of this in a series of templates used by an
open source code generator on SourceForge. I don't claim that it is the
best for any application, but it has it's place. The generator and
templates are all all downloadable from the project summary page at:
https://sourceforge.net/projects/dbobjecter

I hope this helps. I am giving a presentation on this at the St Louis
C#.NET users group September 2003 meeting held at the Microsoft Midwest
regional office. The meeting is open to the public. I am not an employee
of, nor endorsed by Microsoft.

For C#.NET Sig User group info see: http://www.stlnet.org/sigs.htm

Michael Lang, MCSD

 

[Versteijn]

Micheal,

Do you have an example application that I can look at?

Thanks for taking the time to anser my question so complete.

Freek

 

[Versteijn]

I also recommended the book to you because it sounded like you were

struggling with the same design decisions I was struggling with a few months
ago and this book would have been very helpful back when I was swimming in a
sea of questions. You'll learn much from this book even if you decide not to
use his framework.

Thank you for taking the time to reply! I will have a serious look at
it at Bol or Amazon.

Sincerely

Freek