Re: Architectural feedback
From: Kapil M (kapil_maheshwari_at_hotmail.com)
Date: 01/10/05
- Next message: JD: "Re: whats the average age of programmers on here"
- Previous message: Brandon Potter: "Re: Architectural feedback"
- In reply to: John Spiegel: "Architectural feedback"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 10 Jan 2005 16:13:38 -0500
Not sure if you have the luxury of a 3rd party option , but in case you do ,
salesforce.com offers a good package which offers support for custom stuff.
its expensive but solves a lot of issues.
-kapilm
"John Spiegel" <jspiegel@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:#wQDPUz9EHA.3980@TK2MSFTNGP11.phx.gbl...
> Hi all,
>
> I'm in the early stages of designing a system that we'll use in-house and
am
> looking for opinions and suggestions for further reading on which
directions
> to take.
>
> Background: Though we're a small company, I'd like to design this with
the
> mindset of a larger company from the start. This will be an ongoing
project
> to encompass a lot of needs, which will generally be variations on
standard
> themes: Customer account management, billing, reporting and other fairly
> common business functions. Most functionality will be accessed from our
LAN
> with WinForms-based apps (assume all client machines are Windows running
at
> least 2000). There will be some limited Web access for employees, e.g.,
> order forms for sales staff. While we may eventually want to build some
Web
> services for sharing informtion, the general pulic website will remain
> fairly autonomous.
>
> The nature of the company and application is that there will be fairly
> frequent releasing of the system, or components thereof.
>
> Current leanings: Most of the functionality will probably APPEAR to be
> (from user standpoint) unified under a single app. There are a number of
> underlying components into which this apparent monolith will actually be
> broken. Aside from various departmental boundaries that will make for
nice
> conceptual breaks. Utilities, e.g., common dialogs, data access and
account
> calculations, will be broken into various solutions. I'm thinking that
> there will be a skeleton client app that provides the system navigation,
> security and user preferences then uses the appropriate other resources to
> provide actual functionality.
>
> A lot of my uncertainties are in determining what forms and in what
> locations the pieces should be. For example, I'm not clear on whether the
> core app must reside on the client or may be run from the server. Is it
> better to leave the individual dll's on the server, or install in each
> client's GAC? My guess is that deploying all components to individual
> clients will give notably better performance. On the downside, that would
> imply updating a number of machines every time we add a new or function.or
> want to release bug fixes.
>
> I've read a fair amount on remoting, serviced components, and related
> functional divisions (a 70-320 prep book, mainly), but have seen little
that
> really ties together when the best situations to use each are.
>
> TIA,
>
> John
>
>
- Next message: JD: "Re: whats the average age of programmers on here"
- Previous message: Brandon Potter: "Re: Architectural feedback"
- In reply to: John Spiegel: "Architectural feedback"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
