Architecture Planning (Azure, MVC)

Hi,

I’m supposed to be designing solution architecture for an upcoming project (clearly the most advance I ever did and guaranteed to drive me nuts over the coming months). I'm trying not to let my knowledge shape the design, and rather create a solid, maintainable design and fill the gaps in my knowledge later.

Was hoping to hear what others think and help me shape this.

In a nutshell it will be an asp.net mvc application running on the azure platform (so I’ll be using azure table services for data storage and blob services for file services).

Been nutting out Entity Framework 4 (don’t know NHibernate at all) over the past few days and figured I’ll use that in the data access layer (c# class library) to map my domain model (another c# class library) to the data storage (still no idea how azure storage work, but will get to that).
My WCF skills are shaky, but I’m thinking of exposing data via services, though right now I cannot think of that being that useful….

* Front End: XHTML, CSS, JavaScript (jQuery & jQueryTools), AJAX
* Web Client: Asp.Net MVC 2
* Domain Model: C# Class library with POCO , interfaces and implementations (will be using Castle Windsor as IoC)
* Data Access Layer: Entity Framework mapping my domain model and data storage
* Azure Storage: … where that book of mine

Any advice, thoughts and critic will be welcome.

Use the tools for the job and not job for the tools...

If you're expecting a lot of usage or traffic, or if your database is going to be large, don't bother using EF at all. If it's a simple site or if the database itself is quite simple (simple relationships) then the EF will be well suited and easier to use. If it's heavy traffic or large/complicated database, look at NHibernate or regular ADO.NET. Remember that the easier the tool, the worse its performance.

WCF is easier than everyone will tell you. The actual coding for WCF will be dead easy, all you have to learn is configuration (the bindings you want, etc). You also always have the option of exposing your WCF services RESTfully if you want your JavaScript to call it.

That of course brings up another point - remember that any web service calls that you make from JavaScript will be public and it means that anybody can make calls straight to the services, using up your Azure resources, so you want to be absolutely sure of what you're exposing.

Web client- ASP.NET, ASP.NET MVC, PHP, whatever. It's probably the least important bit in any architecture.

OK, another thing. You're also mixing different levels of architecture here; for example IoC isn't really important in architecture, that's a development decision, or rather an architectural decision specifically for code. As inane as it may sound or feel, you do need to make your diagrams, and the diagrams need to represent different levels. So start with a high level diagram that describes the parts of the project. You'd have your Azure boxes, web client, along with actual functional pieces of the app.

Then you can have the technology bit with technology decisions (Azure, C#, EF, nHibernate, midgets, ASP.NET MVC).

The IoC becomes the third level when you're doing your development and usually crops up much later.

The reason diagrams are helpful is so that you don't end up changing things on the fly but have a physical object that becomes your altar of worship.

And finally, another thing to note - using new technologies is great, but you have to be sure about them. If you haven't used those technologies before, how do you really know it's going to work well for you? That's where PoCs come in. The point of an architecture is to pick a tool that is based on the functionality, so you identify a functionality (I want to let users perform intensive searches across our 30 tables) and identify what could potentially do that. Run comparisons, and there you go. Of course this all falls under 'elaboration' as it's called here, and is a matter of time. Most teams consider planning and elaboration a waste of time, so it depends on your company culture and how well they receive news of "Oh, we'd like to sit and think for a few weeks, eh eh eh??" OTOH, if there's no time for a PoC, then it's questionable why you're using something that you don't fully know about. OK for tiny projects, but for big important projects, not quite.

Thanks a lot for your reply.

So you are suggesting using normal Ado.net in the data access layer rather than some ORM?
(Will be a fairly complex database, even though from the business specs I gather it will not be heavily used). In the end the client apps are just going to call mydatalib.whatever.getmesomestuff() anyhow.
It's true that I lost focus in that ORM's only benefit is making development easier. (just had a lot of ooh, aah the last two days seeing what you can do with EF.

How about reporting? All my work in the past I created my own reporting functionality (pretty much pulling data and use some excel automation, but that was years ago.

WCF...hmm. I'll leave that out for now. I cannot really see where it fit into the picture, and can just be added on top of the data access layer if required later (no?)

Thanks for that second one. Very helpful (obviously I never really had to do the architecture planning). To be honest this is only my second really big and complex project ever (and first with me being involved at this level)

Quote:

---

Originally Posted by Krokonoster

Thanks a lot for your reply.

So you are suggesting using normal Ado.net in the data access layer rather than some ORM?
(Will be a fairly complex database, even though from the business specs I gather it will not be heavily used). In the end the client apps are just going to call mydatalib.whatever.getmesomestuff() anyhow.
It's true that I lost focus in that ORM's only benefit is making development easier. (just had a lot of ooh, aah the last two days seeing what you can do with EF.

---

I don't know how much experience you've got with projects but many a-time I've seen wonderful projects ruined by some guy who picks up something and starts using it without considering consequences (or telling anyone). When questioned, I get answers like "Well, I saw a presentation on it yesterday and it looked really easy." Well, whoop-dee-doo, the presenter is usually an evangelist and is trying to show you how wonderful it is. Of course he's going to show you what always works.

But anyways, about your question - if it's not going to be heavily used, then it's implying that performance isn't important to you (which in turn means it doesn't matter what you use, you can still go EF/L2S/ADO.NET). Then it comes down to complexity. You're saying it's complex, are there a lot of tables and heavy relationships between the tables? I suppose this is the crucial bit which you, as the architect, will decide. I won't be able to tell you without going into the whole project with you. So have a good look, then decide.

Quote:

---

How about reporting? All my work in the past I created my own reporting functionality (pretty much pulling data and use some excel automation, but that was years ago.

---

Reporting :sick:

So I've done reporting using custom pages (regular ASP.NET pages talking to my own logic and SPs) and I've done reporting with SSRS and CR. The problem with SSRS and CR is that while you get great control and ease of design, you're somewhat limited by the data control and performance. So it's a very similar situation - is there going to be lots of data, will you be reporting on data going years and years back? Or will you be archiving data so that the reports only go back x months? If you won't have a lot of data, you should be fine with any third party tool, else for heavy reporting, consider doing it custom (it's just like a web page, but with performance considerations)

One thing I can advise is that it'll help if you set up a separate reporting database with data replicated from the main database to the reporting database. This helps ease the load off the main database especially when there's a lot of data to report on.

Quote:

---

WCF...hmm. I'll leave that out for now. I cannot really see where it fit into the picture, and can just be added on top of the data access layer if required later (no?)

---

Yeppppp.

Just deleted a lot of stuff I wrote here until I realized my head is in the wrong place (at development, rather than architecture).
I'm rather going to take the client's specs and derive from that some docs and graphs until I have a clear picture of what is required (trying not to be a developer while at it..dang, it's hard).
Bookmarked this one, as you turned it into something educational (at least for me).
Thanks again.

Not to gloat, but I feel like I can head into architecture some day. :p

But what does suck about this whole thing is that clients NEVER know what they want. Part of being an architect is taking the developer hat off and dumbing yourself down to that in-between level where a client can understand you, but just smart enough so that a dev can understand you too.

http://www.dilbert.com/dyn/str_strip...trip.print.gif