Need advise on application architecture
Versteijn
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
Versteijn
Elliot M. Rodriguez
Have a look at Microsoft Data Access Application Blocks. They are helping me
enormously with architectural issues related to data access.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daab-rm.asp
--
Elliot M. Rodriguez, MCSD
*** It would take 227 cans of Mountain Dew to kill me***
"Versteijn" <vers...@538mail.nl> wrote in message
news:4d19834f.03072...@posting.google.com...
Gavin Joyce
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" <vers...@538mail.nl> wrote in message
news:4d19834f.03072...@posting.google.com...
Tony Perovic
two or more classes. The code in the first two datasets is mostly
duplicated in the third dataset.
Now, for an application with, say, fifty tables, you'd need well over
a hundred datasets to cover all the combinations. How much duplicated
code is that?
Strongly typed datasets provide a cleaner syntax:
MyDataSet.MyTable.MyColumn
instead of
MyDataSet.Tables("MyTable").Rows(0).("MyColumn")
but that can be mitigated by using variables
Dim dr as DataRow
Dim dt as DataTable
dt = MyDataSet.Tables("MyTable")
dr = dt.Rows(0)
dr("Column1") = <new value>
dr("Column2") = <new value>
....
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.
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.
TP
"Gavin Joyce" <ne...@gavinjoyce.no.spam.com> wrote in message news:<#dHLJniU...@tk2msftngp13.phx.gbl>...
Michael Lang
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/type/Patterns/Enterprise/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
"Tony Perovic" <tonyp...@yahoo.com> wrote in message
news:1940c82b.03072...@posting.google.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
tperovic
to enforce the business rules. These business objects fetch, insert, update
and delete themselves from the database. Only the business objects call the
data access layer while the UI layer only deals with these business objects.
I got the book primarily because the first chapter describes several
possible approaches to building a Web or WinForm application using ADO.NET.
In it, the author described all the roadblocks, deadends and design
decisions I had to make while learning VB.NET and ADO.NET. Things like: you
could do it this way but then you'll have that problem or you could do it
that way but then you'll have this problem. His conclusions aligned with
mine so I got the book.
All the other books and websites I looked at, including Microsoft's own
tuorials and walkthroughs, contained code examples that were academic but
not practical. For example, you can use DataSet.Fill() sometimes (maybe even
most of the time) but I kept running into problems that couldn't be solved
with DataSet.Fill(). It was kinda like high school physics class when, to
solve a problem, we were told to ignore friction. Well, in the real world,
you cannot simply ignore friction when solving a problem.
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.
Good luck,
TP
"Versteijn" <vers...@538mail.nl> wrote in message
news:4d19834f.0307...@posting.google.com...
Versteijn
> 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
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...
=======================================================================
Michael Lang, MCSD
"Versteijn" <vers...@538mail.nl> wrote in message
news:4d19834f.03073...@posting.google.com...
Versteijn
Do you have an example application that I can look at?
Thanks for taking the time to anser my question so complete.
Freek
Versteijn
> 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
Michael Lang
"
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
"
You could use this generator against the sample pubs database to see an
example. Or, create a simple database with one table for a really simple
example, such as...
table name: Employee
primary key: EmployeeID
type: uniqueIdentifier
other fields: FirstName, LastName
types: varChar
You will need SQL server or the free MSDE database to run the generator.
Michael Lang, MCSD
"Versteijn" <vers...@538mail.nl> wrote in message
news:4d19834f.03073...@posting.google.com...
Versteijn
I have thought about combining custom classes with datasets. So I will
model my domain with my own classes and have data functions that
return these classes or a dataset (depending on the function chosen).
That way I am flexible and can very easy bind data to controls.
Freek Versteijn