Last post Sep 15, 2014 02:32 PM by jammycakes
Sep 14, 2014 09:30 PM|Xequence|LINK
I am reaching a point in my career where I would like to be able to analyze the references of dll's to verify that the architecture is able to scale. I have read some documents like
but alas I am at the point where I generate a .dgml document and compare and contrast between what I have and still find myself between a rock and a hard spot on saying this is right or this is wrong or this can be improved.
Is there a way I can drop in my .dgml file somewhere to verify on the surface that this is good, but you could insert caching here and here, for example. Thanks in advance.
Sep 15, 2014 04:34 AM|jammycakes|LINK
I'm personally of the opinion (based both on my own experience and that of prominent thought leaders in the industry) that the n-tier architecture adopts a very naive approach to scalability. It advocates a horizontal separation of concerns between your
different layers which is difficult to maintain, resistant to the changes that you need to make on a daily basis, and usually doesn't work anyway when you do need to move from a single tier to several, simply because what works when you've got everything on
one machine doesn't work when you add in the overhead of communication between the different tiers of your application. (See
this article by Martin Fowler for a discussion.)
A far better approach is to partition your code vertically -- separate your concerns by business functionality instead. The buzzword you need to know here is "microservices." For example, you may want to move your entire payment processing system to a different
server, or separate out your front end website from your back end admin site, or if you're implementing a login system and using a slow password hashing algorithm such as bcrypt (which you should be: fast password hashing algorithms are vulnerable to GPU-based
brute force attacks) you may want to have a separate cluster of servers to handle that specific task.
My key advice here is: measure first and then base your decisions on that. A comprehensive set of analytics will take you a lot further here than a .dgml diagram.
Sep 15, 2014 11:04 AM|Xequence|LINK
I thank you for your response, jammycakes. The next question I have is when I am interviewing and they ask me about separation from presentation,application,and data access layer I always seem to say that I can put the business logic wherever I want. I tell
them I put it in between the data access layer, typically the orm and the call from say a controller, and I seem to get mixed responses.
Is this something that is brought out by using ioc that allows us to separate out the business requirements of our code as apposed to the physical tier separation you speak of?
The business does change their mind often, which is why I feel having ioc implemented is a saving grace when I have to change the implementation on the fly and maintain solid principles in the process. Thank you in advance.
Sep 15, 2014 02:32 PM|jammycakes|LINK
If you're interviewing, the important thing is to be able to justify your position here. IMO "just put the business logic wherever you want" isn't a good answer -- it's better to explain why you are putting things where you are putting them. For all its
flaws, the traditional BLL/BOL/DAL architecture is still widely used and a good starting point, so if you're suggesting an alternative, present the two together and compare and contrast them.
My preference for a vertical rather a horizontal separation of concerns comes from my experience with Python's Django framework, which encourages that approach with its concept of "apps" which are similar in some ways to areas in ASP.NET MVC. IOC containers
are really a separate issue, though the two concepts still play well together. While I don't like the over-zealous approach to separation of concerns that many people adopt in order to try and make their persistence mechanism swappable, a partial separation
of concerns between your layers for testing purposes is fine and good. It's several orders of magnitude easier to make your mock objects behave like Entity Framework than it is to make NHibernate or RavenDB behave like Entity Framework.
Finally, do try and develop a feel for the kind of changes that you are asked for most frequently and look for ways to architect your solution with those particular changes in mind. This is generally something that comes largely with experience.