As I have been learning about software development the last 2 years the more I learn, it seems the more gray areas I am running into. One gray area I have issues with right now is trying to decide how many layers an application should have. For example, in a WPF MVVM application what fashion of layering is ok? Is the following too separated? When I mention layering I mean creating a new class library for each layer.
Presentation (View)
View Model
Business Layer
Data Access
Model Layer
Utility Layer
Or for a non MVVM application is this too separated?
Presenation
Business
Data Access
Model Layer
Utility Layer
Is acceptable to run layers together and just create folders for each layer? Any coloring of this gray area would be appreciated.
The answer is, it depends. First off, a separate class library doesn't always mean a separate "layer." A layer is a conceptual grouping of related functionality, that may or may not manifest itself in a single assembly.
How many layers you create is really dependent on your problem at hand. Traditionally, a WPF MVVM application will contain at least the 3 layers (Model, View, View Model) but it can really be varied. Often times I see the Views and ViewModels in the same assembly and the models in their own assembly (usually because the Model objects are POCO's that are used in other contexts)
There is really no silver bullet that answers your question, it is entirely dependent on your problem. The advantage of "layering" and separation is to increase maintainability, promote code re-use, and increase overall clarity (to name a few).
I would argue that if you are not reaching these goals with your current layering solution then you have room to improve. If increasing the layers is decreasing the clarity or maintainability then you have gone too far. If you have only a single "layer" and it is becoming bloated then you have an opportunity to add a layer.
The bottom line is don't over engineer something for the sake of following a strict "pattern." If the pattern has clear advantages to you and your problem at hand then implement it, but understand why you are doing so and what the goal of each "layer" is.
Consider the following areas:
Speed
Reusability
Readability
Development time
Modification speed (the right words to describe this point are escaping me. Edit - Maintainability was what I was looking for [stolen from someone elses answer])
Application footprint (scale and literal size)
Your development team
...then adjust your architecture based on which of these you value. I'm probably missing some other important parts, but you get the idea. There's really no right or wrong answer to this.
An application only has too many layers if the layers themselves become a hurdle to the maintainability of the project as opposed to improving maintainability.
The exact number of layers that is too many is 1 more than is needed.
Layered Architecture: This article describes a concrete example architecture for .NET/WPF Rich Client Applications. Furthermore, the architecture shows in which layer you find the participants of the Model-View-ViewModel (MVVM) pattern.
Related
I am trying to use the Model View Presenter (MVP) pattern for a software that I am writing. I am using C# and Windows Forms, althought that should not matter for answering my question.
I have multiple "MVP-structures". One, for example, is handling retained mode graphics where I can draw geometric shapes on a canvas. Another one is taking these shapes, doing some analysis on them and putting the result somewhere else. There are potentially many events that cause controllers to manipulate data somewhere which then causes cascading manipulation of data in yet another place and so forth.
My fear is that I will eventually loose track of what is changing what if I do not organise my software properly. I can think of two ways to organise the interactions between programm parts occuring in my software: either hierarchical or switch board-like.
My question is: Are there any well known approaches or patterns, that I should look up to organise my software? I would need a starting point for my web search.
I think your intuition is right. If you create many events that cascade you are going to end in trouble. I've seen many times over-complex applications due to out of control eventing. This makes the code very difficult to debug and improve.
First thing it came to my mind was the mediator pattern. Elaborating a bit more I would have central classes that manage parts of the business logic. I would have the model in each of the MVP lightweight , basically being a client that asks the server (one of this controller classes) for more complicated business logic. The idea is to have every model of the MVP classes interacting with as few classes as possible (core business logic) and avoid interacting with other MVPs (which will have more specific business logic)
In any case I would limit as much as possible the classes that throw and listen to events and would centralize this in as few places as possible. The observer pattern can help here. Also having a client-server architecture with a service layer containing the heavy business logic can help making this decoupled and maintanable in the future.
The pattern service layer from the fowler classic "patterns of enterprise application architecture" could be good reading too.
I'm creation an application with over 70 table in database and it will be increased in the next phases.
I use Asp.net MVC: Model, Entity Framework, View Models, Repositories, Views, Controllers, Action Filters, References, Multi languages,....
What is the best place for these parts in my solution?
I have seen different ways to splitting a solution. For example:
- Solution
- Core.UI
- Domain
- UI
- Models
- Persistence
- Core.Test
- UI
- Content
- Controller
- Views
- Scripts
Or another says split it to
- Solution
- Model
- Entities
- Web
- References
Or
...
What is your opinion about DDD (Domain Driven Design)? and how you implement it? Do you recommend it?
I want best flexibility in my project and best choice because
when a project is big, it will be harder to change its structure.
I would like to exchange information in various forms (Web and html,
client applications, mobile, xml....)
I want to change and build fundamental parts of a my project
separately (now and in future)
If you could help me with details or examples.
Thanks a lot...
The key thing here is that you want to avoid coupling so that you can stay productive throughout the development of the app. In order to do that, you want to do a Service-Oriented Architecture.
Instead of n-tier apps which break down the problem into horizontal slices (layers) ,
Service-Oriented Architecture instead takes vertical slices of the application (services).
Start with this video by Udi Dahan if you want to learn the basic ideas of Service-Oriented Architecture. Hint: you're starting off on the wrong foot if you've already designed the database.
The two dudes whose stuff you want read here are Udi Dahan and Greg Young. I would also recommend the DDD Google Group to ask more detailed questions. DDD questions don't always fit StackOverflow as well as other computing questions because they're so nuanced and usually require a lot of back and forth to get to the bottom of the issue.
It is not easy answer this question directly. It depends your business needs, scale of your application etc.
There is a reference implementation from Microsoft Spain. Although it has some drawbacks, it is still a good starting point. If you have enough time, just decide which concepts / patterns are needed and which are not.
http://microsoftnlayerapp.codeplex.com/
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I am looking at different options for persistence modelling in Windows Phone using Isolated Storage. One of the ideas I have come up with was the concept of each object handling its own (were it makes sense of course) persistence, rather than making a repository or other such entity for the purpose of saving objects.
I can't seem to find any good information on this method of persistence which leads me to believe I may have stumbled onto an anti pattern of sorts.
Has anyone approached persistence in this manner? If so what are your for's or against's in relation to this approach.
There are several undeniable truths in software development:
A prototype becomes a product before you know it.
An app targetted "just for platform-x" will soon be ported to platform-y.
The data-store will change. Probably as a result of #2.
There are more ( :) ) but these are enough for to answer your question:
Go with a respository so your objects can be tested, know nothing about persistence, and you can swap out data stores (even go over the wire!) Might as well plan for that up-front.
Sounds like you're talking about the Active Record pattern? It works for some folks but there are criticisms against it (mostly from a testability / separation of concerns standpoint).
The biggest issue is that you end up with persistence logic spread out across all your classes. That can quickly lead to bloat, and it also embeds assumptions about your persistence technology all over your codebase. That gets messy if you need to change where or how you store your objects.
Those assumptions also make automated testing more difficult because now you have a persistence layer dependency to work around. You could inject a repository into the object to counteract some of this stuff, but then you're implementing a repository anyway. :) Better to just keep the core classes entirely peristence-ignorant if you can...
On the plus side, it's a simpler pattern for people to grasp and is a quick way to get things done on a lightweight project. If the number of classes is small it could be the quickest way to get from A to B. I still find myself building out separate repositories on small projects however, I just can't stand having persistence stuff mixed in with my business logic.
Cons:
Violates Single Responsibility Principle (SRP)
Hampers testability
Tightly couples you business logic to your database
Pros:
Is simple to implement
Basically, if your data model is flat and simple, and your application requirements are modest, Active Record might be a good choice; however, it starts to break down when your mapping requirements get a bit more complex. More robust ORM patterns like Data Mapper become appropriate in cases like these.
Pros
simplicity
Cons
breaks separation of concerns
tight coupling of business logic with database
makes testing much more difficult
This pretty much boils down to testing becoming much harder, and decreasing the time before you have to do a major refactor in your project.
At the end of the day you need to weigh your goals and concerns for the project and decide if the loss of testing/verifiability/cleaness is worth it to gain a simpler system.
If it's a simple application, you're probably fine to drop the DAL layer, and go for the simpler model. Though if you application has lots of moving parts and is of considerable complexity, I would avoid removing the DAL as you will want to be able to test and verify your code well.
It flies in the face of using a Data Access Layer...not that there's anything wrong with that.
I don't know MVVM. I always follow 3-layer patter where one layer is UI, another layer is Business layer and last layer is Data access layer.
In this layer we send request from UI to Business layer and Business layer interact with data access layer. In this pattern, everything goes fine then my question why should one learn MVVM. What is the advantage of MVVM. What are the things can be done very little effort using MVVP. Please discuss in detail. Thanks.
The Layers
As opposed to what ppl wrote before me - the MVVM pattern is not about splitting the UI Layer into 3 layers, it's about splitting the UI Layer into two additional layers - The View and ViewModel.
so if we had DAL, BLL, and UI, now we have Model(DAL & BLL) and ViewModel + View (instead of just one layer UI).
it's still 3 layers but orchestrated differently (and if you really think about it - DAL was never really a layer - it's a helper class at most, so the aforementioned 3-layer was in actuality just 2 layers, that are now becoming 3 layers in MVVM).
The Reasons
if you think about it, you'll see that in 3 layers architecture, usually the UI is mixed with presentation code, and application logic code. this violates SRP (Single Responsibility Principle) and is bad for several reasons.
in MVVM the UI Layer is separated into two layers. the ViewModel, which is in charge of the Application Logic, and the View, which is in charge solely on presentations.
This allows you three very important things:
better code Maintainability.
easier to work with VS designer and Blend. aka Blendability. (this is arguably the strongest feature of MVVM. It really boosts up productivity)
allows for testing of the ViewModel with automated tests, whereas up until now we had to test the UI itself, and doing automated tests on UI is complex. This is called Testability
on a personal note; I've been writing in n-tier architecture for years. I started practising MVVM a little over a year ago. It could be a rough ride in some times, but man, it's really worth the effort.
MVVM is for building the UI layer. It is a pattern that enables a very nice interaction between your business objects and the UI-framework. You don't have to change your 3-Tier pattern. MVVM is on another abstraction level.
Here you find a very good video introducing MVVM and probably answering a lot of questions.
MVVM is arguably a three layer architecture itself. Those layers all exist within the same application.
"3-layer" also sometimes refers to n-tier architecture, which is more about separating the UI, the service layer, and the data layer, onto separate servers. If you have that sort of layering, then MVVM will not replace it. It will only augment the UI layer, splitting it into its own three layers.
Here's a write-up of MVVM that shows some relation between classic MVC, through MVP and MVVM:
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx
Also see my answer to this other question. It explains some of the reason you would use MVVM over older variations on MVC.
MVVM is specifically relevant to WPF, Silverlight/Moonlight and Windows Phone 7 because it takes advantage of the powerful databinding that is built into these frameworks.
I'm developing an three layer ASP.NET application with C# and Visual Studio 2008 SP1. I'm using WebForms.
I'm wondering to convert that application to a Silverlight application. Maybe I can reuse a lot of code of ASP.NET layer.
What do you think about?
Assuming you have the typical presentation, business logic, and data layers, and also assuming that you have separated your code diligently into these layers, you should be able to replace your Web Forms with a Silverlight interface and leave your BL and DAL intact.
Real projects tend to be somewhat messy, however, making such a transition more difficult. If you're using SqlDataSource you might have problems.
Those are some good points #Andy, and to expand on what he said:
i'm doing that very same thing right now. Because i have a rather comprehensive business layer, i have been able to do a lot of work (a couple of weeks worth), and in that time i have only had to add one function to that business layer. This is important because it reduces the amount of testing required. It also makes any remaining testing easier as it is easier to compare the output of the old version of the application with the new version.
One pattern that really helped to achieve this was the facade pattern. I built a WCF layer that sits over top of the business layer, and by using the facade pattern i can return results that are more suitable for the new silverlight interface, without interfering with the business layer.
It is most likely though that your new UI will have a drastically different architecture than the ASP.NET version. You will be able to achieve a far cleaner separation between UI, code and data. Some of the ASP.NET code that i was quite proud of looks positively mangy next to the equivalent silverlight code. Be prepared to chop your old code up, and eliminate those business rules from the immediate code behind :)
If you're goal is simply to replicate the UI behaviour as delivered by ASP.NET then yes assuming good partitioning you could re-use quite a bit of code. You'd have ask why you would want to do that though.
On the other hand if the goal is to provide a much richer interactive experience to the user then its likely that you'll find even a well designed business layer just doesn't behave the way such a radically different UI needs it to.