Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am currently investigating multi tier architecture design for a web based application in MVC3. I already have an architecture but not sure if its the best I can do in terms of extendability and performance.

The current architecure has following components

  • DataTier (Contains EF POCO objects)
  • DomainModel (Contains Domain related objects)
  • Global (Among other common things it contains Repository objects for CRUD to DB)
  • Business Layer (Business Logic and Interaction between Data and Client and CRUD using repository)
  • Web(Client) (which talks to DomainModel and Business but also have its own ViewModels for Create and Edit Views for e.g.)

Note: I am using ValueInjector for convering one type of entity to another. (which is proving an overhead in this desing. I really dont like over doing this.)

My question is am I having too many tiers in the above architecure? Do I really need domain model? (I think I do when I exposes my Business Logic via WCF to external clients).

What is happening is that for a simple database insert it

(1) create ViewModel

(2) Convert ViewModel to DomainModel for Business to understand

(3) Business Convert it to DataModel for Repository and then data comes back in the same order.

Few things to consider,

I am not looking for a perfect architecure solution as it does not exits. I am looking for something that is scalable. It should resuable (for e.g. using design patterns ,interfaces, inheritance etc.) Each Layers should be easily testable.

Any suggestions or comments is much appriciated.

Thanks,

share|improve this question

migrated from stackoverflow.com Aug 20 '11 at 12:56

This question came from our site for professional and enthusiast programmers.

add comment

3 Answers

I'll be very general so sorry if it is nothing new for you, I know that's boring:

  • adding a layer adds flexibility but costs some performance
  • adding a layer does not improve scalability (it has to be addressed separately at every layer that creates bottleneck)

I do not know your stack, but similar applications usually consists of database, middleware (domain object with their mapping to database, business logic) and frontend (web interface for humans).

Depending on situation some layers can be merged (embedded database, business logic and frontend as single web app) - that is OK as long as you keep the dependencies clean (no cycles) and you already know where to cut to divide the siamese twins when it becomes necessary.

share|improve this answer
    
Thanks for the reply. Could you please elloborate on "long as you keep the dependencies clean (no cycles) and you already know where to cut to divide " prob with an example? –  activebiz Aug 20 '11 at 6:36
add comment

I think that repositories and the domain model could be collapsed into into one tier. Repositories are supposed to hide low-level CRUD logic from clients (http://martinfowler.com/eaaCatalog/repository.html). Queries to them should return domain objects. I would even say that repositories and the domain model form the contract of the data access tier. The business model should know only this contract. Whether you consider it its own tier is up to you and your requirements.

It also depends on your requirements, whether it's worth it to have your own business logic tier. If you have different clients, definitely yes. Let all your clients access the business tier, which in turn accesses the data access tier through a facade, which knows and queries the repositories and returns domain objects.

If you have only one client, but e.g. your business logic involves resource intensive computations or you have certain security concerns, it might still be appropriate to have a dedicated business layer, which encapsulates that. Otherwise you might include business logic into a (well-specified) area on the client side. It depends...

share|improve this answer
add comment

Developing in layers increases complexity and programming effort. You need to justify what good a business layer would provide vs. a business tier. Personally I don't know many cases for regular LOB application to demand a business tier for scalability. I am not sure what Global is exactly, but the rest are your GUI and Data stuff which you can't avoid separating any way.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.