At work, we are planning our first full-blown asp.net application. Therefore, we decided to do it as right as possible... basically it's a computer inventory management system, which keeps track of computers, servers, lines, etc. The users can open a "Call",
which is basically a user calling and reporting a problem, notifing the technicians about it. The technicians (the other types of users) can then look at the list of "Calls", and go to the source to fix them, they can also look at a call's details, and at
the user's computer details (what OS, CPU, etc..) So far so good... As i said, we want to do this the best way possible, so we decided to make it an N-Tier application. (duh :P) So this is how we thought of doing things: Presentation Layer/Facade: will be
composed of ASPX pages and codebehid. BLL: This will have two types of classes - 1. "transport" classes. these classes are like trucks - their only function is to contain data. Naturally, collections will be amongst these classes. For instance, we will have
a "ComputerInfo" class, whch will contain compuer-related properties (CPU, OS, size of HDD, etc.) 2. "Doer" classes. classes that have mostly methods. these classes will handle the BL, like opening DB connections (yes, DB connections will be handled at this
layer), sending mail messages, etc. the DAL: will be made of "components". each component is responsible for certain entity, in relation to the database - for example, we will have a component that is responsible for calling queries/SPs that are related to
workstations, another will call SPs related to servers... etc etc. To send the data to the database, the DAL will serialize the BL's "trucks" into XML, and will send it to the Oracle DBase. Oracle will then (using SPs) deserialize them, and update the data
as needed. The DAL will also contain a special class, which will handle connections, transactions, and SPs - methods like "ExecuteSP" or "BeginTransaction" or "ExecuteSelectQuery" will be there. This class will be used by both BL _and_ DAL, as BL will handle
the connections/transactions, and DAL will handle the execution of querys. I would like to hear your opinion on this design - where are the flaws, what can be improved, etc. thanx :-)
There are 10 types of people in this world - those who can count binary, and those who cannot.
::Presentation Layer/Facade: will be composed of ASPX pages and codebehid. Naturally. ::BLL: This will have two types of classes - ::1. "transport" classes. these classes are like trucks - their only function is to contain data. ::Naturally, collections will
be amongst these classes. For instance, we will have ::a "ComputerInfo" class, whch will contain compuer-related properties (CPU, OS, size of ::HDD, etc.) ::2. "Doer" classes. classes that have mostly methods. these classes will handle the BL, like ::opening
DB connections (yes, DB connections will be handled at this layer), sending mail ::messages, etc. Ok: * You DO know that an object is STATE and METHOD? A "transport class" is not a business object. You should really work with real objects. The "Doer" classes
(Service- or process classes) are fine. But they should NOT NEVER EVER handle DB connections. THis is not their responsibility, it is the responsibility of the - data layer. ::the DAL: ::will be made of "components". each component is responsible for certain
entity, in relation ::to the database - for example, we will have a component that is responsible for calling ::queries/SPs that are related to workstations, another will call SPs related to servers... etc ::etc. Hm. And whree is the logic deciding when to
use what operation? Dont tell me it is in the business layer. it does not belong there. ::To send the data to the database, the DAL will serialize the BL's "trucks" into XML, and will ::send it to the Oracle DBase. Cough. What? Are you serious? You go all
the way down into the DAL of a client/server application just o THEN turn around and use XML just to tranport the data into the server? ::Oracle will then (using SPs) deserialize them, and update the data as needed. Hm. Well. Ever thought of just sending the
data to sp's (or the tables)? ::The DAL will also contain a special class, which will handle connections, transactions, and ::SPs - methods like "ExecuteSP" or "BeginTransaction" or "ExecuteSelectQuery" will be ::there. This class will be used by both BL _and_
DAL, as BL will handle the ::connections/transactions, and DAL will handle the execution of querys. What for, if all the y do is offload what they SHOULD do into the oracle database? ::I would like to hear your opinion on this design - where are the flaws,
what can be ::improved, etc. Is there any sane reason you think to have for using XML? I love XML, but I would never dream it up to operate on that level of my applications - it makes hardly any sense in the DAL. XML is slow, a ressource hog, clogging up network
connections etc. etc.etc. Ok, it has it's advantages, but - frankly- thescenario you describe is exacltle one where XML can not use any of it's advantages and you are left with all the negatives. Your business layer is a little too weak for me, and your data
layer seems to not do what a data layer is imho supposed to do - as it is way too coupled with the business layer. The nyou have a lot of confusion where you handle the database connection. You seem to handle it in the business layer (you should not), in the
data layer and somwhere between this. Not good. Do you have any UML diagrams for your design?
Thanx for the reply :) >> You DO know that an object is STATE and METHOD? Of course :) Are you saying i should merge the "Doer" classes and the transport classes ? >> But they should NOT NEVER EVER handle DB connections. THis is not their responsibility, it
is the responsibility of the - data layer. They do not... they don't explicitly call OracleConnection, they call that special class in the DAL (let's call it DBConn), and *that* class hadles the connection. However, the decision on "when do i open the connection"
is up to the BLL. Consider a situation where you want to run 2 transactions on one BL operation. I cetainly do not want to open 2 connections for that. Since each DAL operation is a stand-alone, it doesn't know whether a connection is open or not - so it's
up to the BL. >> Hm. Well. Ever thought of just sending the data to sp's (or the tables)? Yes -- i did. Most of my entities contain more than 15(!) properties. The code of adding them as parameters to a SP, or StringBuilding a SQL string is long, repetitive,
and - well - ugly. I thought that XML Serialization will make things cleaner.
There are 10 types of people in this world - those who can count binary, and those who cannot.
The info class approach is java-ish. I don't think it's too bad, it does have some advantages. Both can be rationalized thinking abstractly. A machine has no knowledge about business processes. A machine manager is the object that knows machine x should be
supported by tech support person y. It also could be responsible for work orders. The machine itself is relatively static... the only changes to the machine are hardware / software changes.
:: ::To send the data to the database, the DAL will serialize the BL's "trucks" into XML, :: ::and will send it to the Oracle DBase. :: Cough. What? Are you serious? You go all the way down into the DAL of a client/server :: application just o THEN turn around
and use XML just to tranport the data into the server? I've implemented a similar design in a couple of projects. We didn't use an Oracle SP, but we did send our data (in XML) from the web-server to the database-tier. I wrote our own transaction service in
C to read the XML and use OCI to insert/update/delete the data in to the database. The design was quite efficient. :: Is there any sane reason you think to have for using XML? I love :: XML, but I would never dream it up to operate on that level of my :: applications
- it makes hardly any sense in the DAL. XML is slow, a ressource :: hog, clogging up network connections etc. etc.etc. Ok, it has it's :: advantages, but - frankly- thescenario you describe is exacltle one where :: XML can not use any of it's advantages and
you are left with all the negatives. You overlooked one of XML's prime advantages: grouping related data into a tree. It was much more efficient to push the tree of data to a C program running on the same tier as the database, and let it handle CRUD. The larger
the tree, the more appealing this design becomes.
::Are you saying i should merge the "Doer" classes and the transport classes ? Depends on what they do. As long as the processes are simple - yes. When the business process turns compicated (which should not be the case in your point - I mean stuff like wage
calculation ,tax returns etc.) they stay as separate process classes. Object normally encapsule "real world items" or "compelx processes". The "Doer" term is the most ugly wording I have ever heard for this. Could you please get some UML books and select some
not so amateurish terms :-) Call them process classes, at least. ::Most of my entities contain more than 15(!) properties. The code of adding them as ::parameters to a SP, or StringBuilding a SQL string is long, repetitive, and - well - ugly. ::I thought that
XML Serialization will make things cleaner. Well, ever through that "repetitive" code is better never written? If you want dynamic SQL, make it as I do (in our O/R mapper, but this is another story): I have a fully configurable DAL here. If you use SP's, still
use a configurable DAL, and have the SP's generated out of the configuration file. @SoulOfReality: ::You overlooked one of XML's prime: No, I did not. I would still not use XML within an application. Ever tried binary remoting protocols? And instead of a C
program a C# service could STILL pick up the data. There is no need for XML. In our EntityBroker I have exactly the same problem: I push a number of changed objects out into the DAL at once. Now, this is not a tree - the tree (or graph) of objects, as the
graph is already decomposed into the individual objects (fields). This is, in it's core, a two dimensional object array. All changed object's data with the order what to do (update,delete,insert). The DAL traverses over the array. MUCH faster than using XML,
where the parsing is much (and I mean much) slower than for a binary remoting channel.
No C. I wrote my own soap-server in C to handle XML transactions. I know most apps don't care about extreme performance, but I'm off the opinion that low-level OCI calls in C on a solaris box is one the most scalable DAL designs. Of course, I spend all my time
coding C# now since I think SQL-Server will be *good-enough* for most everything I want to do. I've only given token thought to intergrating my O/R Mapper with Unix C.
>>If you want dynamic SQL, make it as I do (in our O/R mapper, but this is another story): >>I have a fully configurable DAL here. >>If you use SP's, still use a configurable DAL, and have the SP's >>generated out of the configuration file. I'm afraid i didn't
quite understand you - what do you mean by "configurable DAL"? how can you generate SPs out of the .config file?
There are 10 types of people in this world - those who can count binary, and those who cannot.
::what do you mean by "configurable DAL"? Well, you can not. But the call TO the sp can be configured. Cmon, it is the same SQL type over and over and over again. Whether it is SELECT * FROM TABLENAME or EXEC spname ( it is a pretty simple operation to have
one generic class that just generates the SQL string taking information from a configuration file plus parameters.
gilad g
Member
45 Points
9 Posts
Opinion on application design
Sep 16, 2003 01:45 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Opinion on application design
Sep 16, 2003 03:34 PM|LINK
gilad g
Member
45 Points
9 Posts
Re: Opinion on application design
Sep 16, 2003 04:01 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: Opinion on application design
Sep 16, 2003 04:04 PM|LINK
SoulOfRealit...
Participant
775 Points
155 Posts
Re: Opinion on application design
Sep 16, 2003 04:16 PM|LINK
thona
Member
20 Points
2923 Posts
Re: Opinion on application design
Sep 16, 2003 06:56 PM|LINK
Stephen Vaki...
Contributor
2540 Points
508 Posts
Re: Opinion on application design
Sep 16, 2003 08:12 PM|LINK
SoulOfRealit...
Participant
775 Points
155 Posts
Re: Opinion on application design
Sep 16, 2003 09:44 PM|LINK
gilad g
Member
45 Points
9 Posts
Re: Opinion on application design
Sep 17, 2003 05:39 AM|LINK
thona
Member
20 Points
2923 Posts
Re: Opinion on application design
Sep 17, 2003 10:29 AM|LINK