Re: OOD/OOP and databases

From: Thomas Jespersen (tje_at_nospam.mentum.dk)
Date: 09/13/04 

Date: Mon, 13 Sep 2004 23:00:12 +0200

Hello Nick

Thanks for you input.

First... Yes, you are right, I haven't read the GoF book yet. I thought I
start with something a bit lighter which Design Patterns Explained was (a
great introduction to OOD though). Is it readable for a .NET guy?

Buschmann... never heard of him (embarrassed smiley here). I took a look on
Amazon... can you recommend a specific book?

I read a lot from the Microsoft Patterns & Practices group. I like the
Application Blocks, although I don't really see them as a design guide....
they are just... well Application Blocks.

Regarding my problem about separating the Business and the UI. I agree that
business rules is much more than validation. But I often find that all kind
of rules are need in the UI. E.g. which menu items is shown, warnings and
other things to make sure that exceptions doesn't occurs when calling the
Domain Model. This might sound odd, but e.g. I might have a rule that I
can't call Customer.AddContactInformation, if the customer is inactive or
unsaved. So I'd make a Property on the Customer called
AddContactInformationAllowed. I use this property to decide whether a
certain menu option is available, and/or I call this before
AddContactInformation, to make sure that it doesn't throw an exception.

For me this kind of interaction is a must to make a usable client
application (which is what's count in the end... at least for me), but I
don't se much of this kind in the OO books. But I will consider splitting up
the Domain Model in two (on for validation like things, and one for hiding
business rules)... I'm just not quit sure that this is doable, if related
responsibilities is to be grouped on the same object.

Thomas

"Nick Malik" <nickmalik@hotmail.nospam.com> wrote in message
news:7MG0d.417794$%_6.111013@attbi_s01...
> 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
    ... If you view the interaction with the domain model as a series of messages, ... > start with something a bit lighter which Design Patterns Explained was (a ... > business rules is much more than validation. ... > don't se much of this kind in the OO books. ...
    (microsoft.public.dotnet.general)
  • Re: OOD/OOP and databases
    ... I, too, have read many of the same books. ... You didn't mention the Design ... There are also a number of patterns books ... change the business rules, you need to encapsulate logic, not just ...
    (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)
Quantcast