>>>>>Hi Frank,
>>>>>
>>>>>>
>>>>>>Thanks Viv,
>>>>>>
>>>>>>I'm open to any advice on a better design. I don't understand why you think it introduces potential problems though, so could you explain that, please? The possible properties will all be defined by me so I will know what is there and what I can use, I've just got into the habit of doing things like this in VFP so that I just need to add any new property to the table and it is magically available for me in the code. I suppose I could just make the properties defined ones on an object and just populate them from thetable when I need to. Is that a better design?
>>>>>
>>>>>
>>>>>It is not likely you will add settings properties to the data and not need to update your application in some way to use them. For this reason using Dynamic properties may be more effort and more fragile than worth it. In addition if the user needs to set or change these setting values, you would most likely need to provide a way for them to do that. The table approach gives them a way if they can access the table, but most you would probably want a form in the application for them to manage the properties. For all those reasons, being dynamic doesn't really add that much value.
>>>>>
>>>>>I would recommend either using the built in MM configuration settings or using a single row in a table where you can back it with a business object and keep everything strongly typed. It is pretty easy to add a column to a table even dynamically when you push out upgrades and then add another property in the entity object. All the complexity goes away and gives you an easy way to work with your settings.
>>>>>
>>>>>If this was a desktop application, I would use the CustomSettings class in MM.
>>>>>Tim
>>>>
>>>>
>>>>Thanks Tim,
>>>>
>>>>so does that mean there is no CustomSettings class for ASP.NET in MM?
>>>
>>>There is and you can use it so long as you will be able to both read and write to the xml file created in your asp.net environment. Check in the Developers Guide under "Overview of MM.NET / Application Settings Classes" This provides strong typing because you back it with properties and the settings are persisted to an XML file that you specify. If you want to have settings specific to individual users then you need to go back to the table and a business object where you can create a row in the settings table for each user and include a foreign key column to the userPK of the user table.
>>>
>>>One thing to keep reminding yourself is Foxpro didn't strong type so things may be more difficult if you try to do them the same as VFP but as time goes on you put some of the old habits behind you and it really does save you in the end.
>>>Tim
>>
>>I feel like we've gone full circle here :)
>>
>>This week looks like a really bad one in terms of time to spend on this project, but I will re-read what you suggested and see if I can get my head back around this.
>
>Yes, we have gone full circle because your original question involved having access to the settings within the business objects. The settings classes are typically a function of the application level. You can use the built in settings classes in Mm and then find a way to pass them into the business object library either as needed, or globally. Or you can use another method such as putting your settings in a table, creating a business object with an entity object and then standard data access methods are available and you can use these in the application as well as you can get to the values from another business object. This is the approach I would most likely take if I had that need.
>Tim


OK, thanks