Re: Best practices for validation (discussion)
From: Sami Vaaraniemi (samivawantsnospam_at_jippii.fi)
Date: 03/10/04
- Next message: Eirc: "Remote Console -- Remoting?"
- Previous message: Rob Windsor [MVP]: "Re: SmartClients..."
- In reply to: richlm: "Best practices for validation (discussion)"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 10 Mar 2004 13:48:27 -0700
Hi,
Here are some of my experiences, mostly in the context of rich or smart
client applications.
In pretty much every business application I've worked with I've ended up
with some business-like logic on the UI layer (call it UI-centric business
logic). This consists of things like simple validation and also things like
'when users selects value X from combo box C, then I need to populate these
other controls with some values and hide some other controls'. This is
business logic because it reflects directly business rules. In real life, it
simply is not an option to do a server round-trip every time you want to do
a bit of logic like this. Users do appreciate quick response time and the
server roundtrip when doing simple UI centric logic is one of the big
reasons why the UI experience with web apps is poor.
In addition to some UI-centric business logic, you'll want to do the real
business logic on the server side. Further, in addition to UI side
validation, you need to validate everything also on the actual business
logic layer. Otherwise your business logic layer would not be safely
reusable outside the client app. You may end up doing some validation twice,
but again this is how it goes in real life.
So it's a good goal to keep the business logic in its own tier in the
server. Nevertheless some UI centric business logic is unavoidable because
minimizing server round-trips is what keeps your users happy.
Regards,
Sami
www.capehill.net
"richlm" <rich_lm@h0tmai1.com> wrote in message
news:%23nLu80gBEHA.1544@TK2MSFTNGP09.phx.gbl...
> I am looking into "best practices" for implementing validation in a n-tier
> application.
> UI is initially Windows Forms, but there will also be some web UI later.
>
> "Is it sensible to try to encapsulate validation logic in a business
entity,
> in order to keep my UI as thin as possible"
>
>
> e.g. I have a text box on my form to enter a social-security number.
> This has a well defined format, e.g as a regular expression
"^\d{6}-\d{4}$".
> It is easy to put the regex validation in Control.Validating(), a custom
> control or an IExtenderProvider, but this is really business logic.
> I really want my UI to ask the business entity "is this valid" (and the
> entity reply "no" or throw and exception if it is not)
>
> I can envision a fairly generic solution using attributes and/or
reflection,
> along with some standard validation algorithms.
> Then all I need to do is map controls to business entity properties and my
> GUI is pretty much done.
> And if that mapping could be done visually at design time (like data
> binding)...
>
>
> I can think of some technical solutions, but as the subject suggests, I am
> hoping to get some discussion on the subject, to get some opinions and
> experiences.
>
> Richard.
>
>
- Next message: Eirc: "Remote Console -- Remoting?"
- Previous message: Rob Windsor [MVP]: "Re: SmartClients..."
- In reply to: richlm: "Best practices for validation (discussion)"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
