Software Design Idea for multi tier architecture

Question

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,

Answer 1

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.

Answer 2

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.

Answer 3

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...

Answer 4

The default approach should be three "layers" or modules (Data Access, Business, UI). If you have any less, or any more, you better have a darn good reason IMO as three layers is the best solution for 90%+ of enterprise projects. More layers means fixes and changes take more time. Less layers can cause confusion and resistance to change as well.

Why I used "layers" in quotes is that mandating that the business layer sits between data access and the UI tightly couples your business logic to your database. For example, what if the user wants to mess with hypothetical situations with your widget instead of getting information about the widget which he owns? This is an operation which requires no data access. The easiest way to do this is New Widget -> Populate Widget from UI -> Call Widget.GetInfo() -> display info.

What if a job wants to access records but does not need business logic? Business and data access should be separate, but I would not say that business sits on top of data access.