Click here to Skip to main content
15,890,512 members
Please Sign up or sign in to vote.
3.00/5 (1 vote)
See more:
I have my current application with the following architecture

1) Web.UI layer (Just CodeBehind Approach)
2) Business Layers hosted as a separate virtual directory and exposed as WCF services
3) Data Access Layer (as a separate assembly)

Now I need to design and consider moving the same to MVC4. Does that mean UI would again trifurcate into M V C thereby the total number of *distinct* entities would now become

1) V
2) M
3) C
4) Business Layer
5) Data Access Layer

or should we do some other re-orientation of the structure? Can some one help clarify the same?
Posted
Comments
Sergey Alexandrovich Kryukov 18-Apr-13 10:38am    
Just notes: I would not call just a list of layers "architecture". Your "as a separate assembly" suggests that you consider boundaries between assemblies too seriously. You should understand that it depends on the layered structure (apparently), but is not the same. Assemblies form finer-grain modularity; and declaration can be easily move from one assembly to another; keep it easy and flexible at first. No, your 5 layers don't look adequate... You are mixing things. For example, business logic should be a part of model...
—SA
José Amílcar Casimiro 18-Apr-13 16:53pm    
Hi Sergey, can you give me a bigger picture of your sentence:

Your "as a separate assembly" suggests that you consider boundaries between assemblies too seriously.

Thanks.
Sergey Alexandrovich Kryukov 18-Apr-13 17:03pm    
I mean that assemblies should not be considered as implementation detail, not only below architecture, but actually below the design of particular types. You need to come to the design of relationshops between major types, and only late design in what assemblies you put them. As a rule of thumb. You see, you hardly can pull an assembly from one tier to another, but you can easily mode some types from one assembly to another (in the same tier). The boundaries between assemblies are too weak and irrelevant, to consider them too early. Abstractions should not depend on implementation detail; implementation detail should depend on abstractions.
—SA
José Amílcar Casimiro 18-Apr-13 17:12pm    
I agree. Thanks for the clarification.
Sergey Alexandrovich Kryukov 18-Apr-13 17:14pm    
Thank you for understanding. I often claimed something like that, but it turned out to be not so easy to explain in general terms.
—SA

1 solution

Please see my notes. Your problem is that you probably misunderstand the whole notion of architecture. Another problem that you try to reduce it to one level with several layers and represent it all as a list of layers. Worse, you are mixing the elements of multitier architecture with the elements of MVC, and even on the same layer.

I like the considerations provided in response to similar question in the answer by user151323 who explains the idea of orthogonal elements of architecture, please see:
http://stackoverflow.com/questions/2690707/does-mvc-replace-traditional-manually-created-bll[^].

See also:
http://en.wikipedia.org/wiki/Multitier_architecture[^],
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller[^],
http://en.wikipedia.org/wiki/Orthogonality[^].

—SA
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900