Re: Design for single database, multiple applications
Re: Design for single database, multiple applications
- Subject: Re: Design for single database, multiple applications
- From: Mark Wardle <email@hidden>
- Date: Fri, 13 Aug 2010 21:39:34 +0100
Thank you both for these replies.
I think I'm learning that just because I don't have budget constraints
(in terms of money) I do have time constraints and as such sometimes
things just have to be good enough, rather than perfect.
As such, deploying, integrating and managing multiple apps may be one
step too far! I'll try to stick to one app and move some more core
items into frameworks to simplify maintenance.
Thanks,
Mark
--
Dr. Mark Wardle
Specialist registrar, Neurology
(Sent from my mobile)
On 10 Aug 2010, at 04:47, Chuck Hill <email@hidden> wrote:
> Hi Mark,
>
> On Aug 9, 2010, at 2:02 PM, Mark Wardle wrote:
>>
>> The time has come for me to sketch out the next version of my patient
>> record system.
>>
>> I have several frameworks and one application. The latter is a bit
>> gnarly (to use a technical term) and unwieldy and I think it would
>> make sense logically (and from a user interface point of view) to have
>> separate applications for different specific functionality.
>
> Why not partition the UI functionality into frameworks and then combine them in the (now probably mostly empty) application?
>
>
>> Is there a WebObjects-way of passing sessions between applications or
>> is it simply a case if using a manually created cookie with an
>> encrypted username and somehow safely providing a time-limited
>> credential?
>
> I once broke up an application into two for the same reason you are considering. I have regretted it ever since. It uses more memory on the server (more app instances) and you have the problem of different sessions on different applications.
>
> If you really want single sign on, look at something like Cosign, or WebAuth or Shibboleth.
>
>
>> I have enabled different sub-applications as part of the single main
>> app dynamically based on runtime data - and I'm definitely undecided
>> whether breaking it up is the right way forward. On the other hand,
>> factoring out the common stuff and creating a robust core framework
>> has a certain aesthetic quality to it.
>
> Based on your description, I'd refactor the common stuff into frameworks and keep the single point of access (application) for the users.
>
>
> Chuck
>
>
>>
>> All opinions gratefully received.
>>
>> Many thanks,
>>
>> Mark
>>
>>
>> --
>> Dr. Mark Wardle
>> Specialist registrar, Neurology
>> (Sent from my mobile)
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden