Question regarding software architecture
Hello.
Currently, I am working on a Loans application for one of our clients. The details of our project is specified below:
-It is based heavily on a former Oracle Forms(front-end)/Oracle 10g system(back-end)
-It is basically a migration from Oracle forms to .Net, because I
think, the management prefers the new look that ASP.Net pages give to
the users and they'd like to improve the layout of the screens. The
back-end will still be Oracle 10g
-For some reason, there is also a management directive that was given
out that we will be creating Web Services to make the former stored
procedures of the Oracle applications "modular" (ie: split them to
atomic pieces of procedures so that it is possible to call the
procedures through the web services if there are other applications
that need to use it)
From my understanding, much of the business processes involved with the
project we are doing are basic create/read/update/delete operations.
With this in mind, I thought, "If I were to design the system, I'd use
the n-tier approach...and just have the data access layer do all the
basic CRUD operations, then encapsulate ALL the business rules in a
business layer in .Net"
For some reason, management did not like that approach again. They said
that majority of the business rules (Yes, even validations for null
fields, or complex/simple computations) should be in stored procedures
and should only be available through web services that we will write. I
am not sure whether this is a good idea or not. In some online articles
I have read, it said that we should always question the use of web
services when all it does is to do CRUD operations and do some very
basic validations like checking for null values or checking if a value
selected from a drop-down list exists in your table (Which, by the way,
I think is retarded, since we are also going to provide a web service
to populate the said drop-down list in the first place with data coming
from our DB. I cannot understand why we still need to check for the
validity of the selected value if all possible values in the drop-down
list will be coming from the back-end in the first place).
My main question here would be, for CRUD operations, is a
Service-Oriented-Architecture a good fit or will we be better off using
an n-Tier architecture instead?
Another thing that I was concerned with was that most of the web
services we will be creating will be returning datasets for a list of
values derived from a query to the tables and that the parameters we
are going to pass are also datasets. From my understanding, our
technical architect's solution for a n"add" operation would be
something like:
1. Front-end guys will put the data they got from the users into a dataset
2. Front-end guys will call our web service and pass the dataset
3. Back-end guys (that's us) will receive the dataset and pick out data
row 0 (since we're only usually inserting one row at a time) then pass
it to our data access layer, construct the parameters needed for the
command, then execute the command.
I asked the architect why we can't just come up with an architecture of
business objects/classes that we can use instead of datasets as, I have
read that classes are better "performance-wise" since they are a
lightweight holder of data and you can probably do a better job of
manipulating them with regard to the business process that the
application will do, but here are his rebuttals:
1. When the db/table schema changes, you'd need to change your
object/classes architecture as well, thus, it's added maintenance. With
datasets, you can just get the db/table schema, put it in an xml file
or use xml readers/writers and then pass it to the front-end guys and
it's much easier to do than using classes.
2. Classes/objects are a pain to pass through web services as parameters/return types.
I have not come up with a response to this yet as I am weighing the
pros and cons of using classes vs. using datasets that is why I am
asking for your opinions. He had a valid point regarding
manually-coding the classes again in case the db/table schema changes,
but I don't know if there are tools or methods out there that are
already existing that can be used to work around this limitation.
As far as passing classes/objects through web services as
parameters/return types, I am still researching on this one and it
would be great if someone could shed light on this issue. I do agree
that in terms of serializing data to/from the front-end guys, datasets
are a much easier option, but I don't know if this is the best way to
do it in the long run or we will be having some problems in the future
because of some limitation that comes with it.
Sorry for the long post. Thank you.