architecture thoughts, potential new team member using new technology

architecture thoughts, potential new team member using new technology

Old forum URL:

matt tag posted on Friday, February 10, 2012

We're considering hiring a web developer who creates kick-butt looking websites but doesn't use any of the technologies we have traditionally used in-house (read: C#, CSLA, ASP.NET, more recently MVC). We purposefully structured the job description to focus on a "web developer" so we didn't limit ourselves to one technology - I thought it could be useful to expand the boundaries of knowledge/experience of my department.

So, if I actually hire this person, we will have some interesting challenges regarding sending data back and forth to our new web-based LOB apps, and I'm wondering if anyone has any ideas and/or resources for accomplishing this.  Do I start reading up on SOA architectures?  Our apps aren't necessarily crossing "trust boundaries", so I'm not sure (after 20 minutes of Google) that this is the correct path to start down. But I've been so locked into my little Microsoft world that I really don't know what's out there for me.

Any advice would be appreciated.



tmg4340 replied on Friday, February 10, 2012

I think it's tough to provide decent advice without knowing the technology stack said kick-butt developer is going to be using.  The level of compatibility is going to depend largely on what he/she uses.

In a more general sense, if they build sites largely outside of the Microsoft stack, then you probably don't have a lot of choice - a service-oriented solution is about all you've got.  You may not be crossing a "trust boundary", but environmental differences are another kind of boundary.  If they're different enough, integrating CSLA directly into their solution may not be possible.  Obviously there have been attempts to get CSLA working in non-MS environments, but from what I can tell they have had limited success (largely dependent on the level of compatibility the particular environments have built into their porting of the .NET framework).

You may also have issues if they choose the "Web 2.0" route - i.e. a very JavaScript/AJAX-heavy environment.  Depending on how you've built your CSLA objects, they may not play as well in that kind of asynchronous environment without some modifications.  I believe that will also pretty much require a service layer, since you couldn't get the DataPortal to play well with JSON.  To be honest, sites built in this methodology are a whole different architectural beast - they generally are much more service-oriented, and there is (at least to me) a somewhat distressing level of business logic contained within Javascript and whatever server-side platform is used (the very duplication that CSLA helps you to to avoid).  But you have similar issues with "straight" ASP.NET/MVC sites as well...


- Scott

Copyright (c) Marimer LLC