views:

40

answers:

2

So I'm having some level of difficulty with architecting a particular solution with some dynamic data elements....

So I've got two places where I'm storing data -- a database and a pdf (although I only write to the pdf - I never read from it). You can think of the pdf working a lot like a database -- except that the schemas for the table and the pdf are different. Different fields will go into the database and the pdf. Users will be able to edit certain fields -- but not all fields. I'm trying hard to enforce a separation of UI and logic here, but I'm running into difficulties. My logic is essentially having to tell my UI what UI elements to create and what restrictions to enforce on them (required, options, etc) so I feel a bit like I'm making a UI from within my business logic; but I don't really know how else to do this with dynamic data elements. When this is done, I have to write to the database and then print the pdf.

You can essentially think of this question as... "I have a ton of disparate data. I need to do different things with different pieces of data. I can't figure out a way to do this generically without making some coding atrocity." Does anyone have any ideas?

A: 

If I were you, I would look at all the information about fields users need to view/edit, and see what common themes I can see. Looking at your question I would probably create a class/structure that contains the following:

struct FieldInfo
{
    string FieldName;
    string DisplayName;
    string DataType;
    bool Required;
    delegate Validator;
    string OldValue;
}

delegate bool Validator(string input, out string message);

I would return FieldInfo[] from the Business Logic, then in the UI use that array to determine what to show the user. This way, even the validation login is the your business logis (using the delegate) and the UI only has to decide what elements to display for each type. You could even go a step farther and have the FieldInfo struct have an element name telling the UI what element to use for that field (Textbox, DDL, etc)

TJMonk15
This is pretty much what I've been doing; it just seemed like a bit of a hack. Thanks, though.
Aaron
+1  A: 

What you're doing is developing an application framework, not an application. You might benefit from looking at other application frameworks (there are a billion of them) to see how others have approached the problem.

I can tell you right now that your project will be successful in direct proportion to how well you've designed the scheme for handling metainformation. Steve McConnell's general rule that data is easier to debug than code is pretty much the guiding beacon for this kind of project.

WPF is really, really well suited for this kind of thing. I've been porting over my own app framework from Windows Forms to WPF and am kind of amazed at how much code I don't have to write.

Robert Rossney
Applying some rules as to what can happen to certain bits of data is ok and has nothing to do with the presentation; yes you'll need a presentation of somekind - but it's reasonable to expect the logic layer to dictate those rules.
Adrian K