Re: OOD/OOP and databases

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Nick Malik (nickmalik_at_hotmail.nospam.com)
Date: 09/11/04 

Date: Sat, 11 Sep 2004 17:40:19 GMT

Yes... that's a lot for a newsgroup.

Start here:
http://www.microsoft.com/resources/practices/default.mspx

I, too, have read many of the same books. You didn't mention the Design
Patterns book itself (Gang of Four: Gamma, Helm, Johnson, and Vlissides) but
it, too, is an excellent volume. There are also a number of patterns books
that describe code in C# that have been coming out in the past two years.

The books do not focus on a particular tier. The Design Patterns books,
specifically, focus on a specific level of abstraction. The Fowler book
focuses on a different level of abstraction. Buschmann takes on the
architectural level. Honestly, to answer your questions, Buschmann is the
best of the group.

The Microsoft site has some very specific advice for the .NET platform with
regards to optimizations... worth looking into.

As for me: my middle tier is normally tailored to one thing: hiding the
business rules. That requires real analysis: what are the business rules...
what will change... how will they change... how will we maintain them.

Config files are not good for business rule changes... they are too
tactical. You can change the name of a stored proc in the config file. To
change the business rules, you need to encapsulate logic, not just
constants. Using pluggable components will only get you so far.

So, if the business layer has very few business rules, it's really thin.
For many purposes, especially for domain tables (lookup tables), I don't
have any logic at all in the middle tier. In that case, I often simply pass
the data through directly from the DAL to the UI layer as an array of
DataRows. I'll even occasionally bind directly to a control (not often, but
for drop-downs, it's good). On the other hand, if the business layer has
business rules to encapsulate, then I will organize the objects so that
managing those rules makes sense. This is where we start to deviate from
"business objects that mirror the database". This is where the design
patterns come in handy. You really have to map your data into objects that
isolate change and minimize complexity.

I've yet to find a tool or framework that does more than simply
copy-and-reflect operations from the database through the middle tier. I
don't use them. WHat a massive waste of time and processing power. Heck...
the DataSet object does a better job than most of these, and it doesn't
require a huge amount of effort to use! (I don't use it either... I'm just
making a point).

As for copying the validation rules: For a thick client app, I'd have the
same validation dll on both the client and the server. That way, you can
insure common rules. Note: business rules are much more than validation.
I'd have basic validation types that I can use in both places, but the rest
of the rules are quite different.

As for use of remoting: depends on the kind and style of scalability you
want to achieve. For my preference, remoting is too tightly coupled for the
kinds of things that I do... I tend toward web services... but that may not
be advice that you can use... depends on your app.

I hope this info is helpful.
--- Nick Malik
      Application Architect
      MCSD, CFPS, Certified Scrummaster
"Thomas Jespersen" <tje@nospam.mentum.dk> wrote in message
news:ecFEdt%23lEHA.2880@TK2MSFTNGP14.phx.gbl...
> Hello
>
> I've been reading a lot of great OOD/OOP books lately (e.g.. Martin
Fowlers
> UML Distilled, Patterns of Enterprise Application Architecture,
Refactoring,
> Kent Becks's Test Driven Development, and also a book called Design
Patterns
> Explained.)... al of them with the focus on Java, because I think the best
> books are targeted Java. But the all fit very well to the .NET platform.
>
> I have one big problem when reading these great books, and that is that
they
> focus almost entirely on the Domain Model (that is the Middle Layer in a 3
> layered architecture). They hardly mention that the code you write is to
be
> used in a UI interface and committed to a database ([PoEAA] might be an
> exception). I find the separation of Business Login and UI to be the
hardest
> thing. And also I find the performance issues when talking to the Database
> to a very tricky thing, that calls for a few hack in the Domain Layer (I'm
> almost only doing thick clients... that is no web).
>
> So I would like to know how you OO Guys really work (references to books
or
> articles would be great).
>
> Don't you design your database the same way that you design you Business
> Model if you are responsible for all 3 layers/tiers?
>
> How much time does you spend on writing the DAL (the mapping between the
OO
> and the Database)? Do you use any kind of O/R Mappers to help you write
the
> DAL?
>
> Where do you place the tiers in a Smart Client configuration? The way I
see
> it the UI and Domain Model must be on the client. Because you Domain Model
> contains a lot of information e.g. about validation the input, and I don't
> want a Server Round Trip every time the users enters something in a
textbox.
> But I'm also thinking about putting the same domain objects on the server
> aswell and use some kind of serialization using .NET Remoting or Web
> Services. Anyone else placing the Domain Model on both the Client and
> Server?
>
> Can you recommend any third party frameworks, which addresses any of these
> problems? I find many of the MS Reference application to be to exotic.
>
> I know these are big questions for a thread in a newsgroup... but never
the
> less, I haven't found any books or articles that really deals with these
> issues.
>
> Best regards,
> Thomas
> MCSD, MCSE+I, MCP+SB
>
>

Relevant Pages

  • Re: OOD/OOP and databases
    ... although I don't really see them as a design guide.... ... business rules is much more than validation. ... don't se much of this kind in the OO books. ... the Domain Model in two (on for validation like things, ...
    (microsoft.public.dotnet.general)
  • Re: How to apply (rather than understand) OO?
    ... Many OO books in the library are about OOAD and not exactly ... OOAD is not enough for database system programming and it has very ... the business rules and the OO guidelines to the interfaces. ... Java is a 100% procedural language. ...
    (comp.object)
  • Re: Complex Business Rules - Domain Model or Elsewhere?
    ... was wondering if there are patterns these days for holding complex ... I have found some books, ... The concepts in the book and website are about how to specify complex business rules as automated test suites written in a form that is easy for the business analysts to understand, author, and manipulate. ...
    (comp.object)
  • Re: Database Design & Normalization Question
    ... understand the logic behind the books, videos, software, ... didn't have to change the database design to store new ...
    (microsoft.public.sqlserver.server)
  • Re: MVC design questions
    ... Instead of a single CRUD GUI program I've got two, the idea being that one can be given to anybody because it can't damage the database (no insert/update/ delete capability at all while the other, which can do these things, is intended only for suitable authorised users: most data is bulk loaded and the update GUI is only there for removing to odd piece of junk and tidying up. ... In fact, i'd create three - a full-access account for the DBA, an account with the ability to edit the data, but not do DDL, for the update app, and a read-only one for the search app. ... I have almost no OO background and have no idea who the currently recognised OO design gurus are. ... That era was dominated by big ideas - big processes, big notations, big books, big words. ...
    (comp.lang.java.programmer)