mercredi 30 mars 2016

Do you like spaghetti or Lasagna


The spaghetti Pattern is an anti-pattern because we can't find any structure clear, most of the components are not reused after and it's not easy when we try to improve or to add other parts, and produce regression in maintenance.
So, why some developers use this pattern? 
the reason that this type of development pattern is initially popular because it's the easiest and the fastest way to let going. No need to plan, then just start and correct, so the test is easier because it depend from a small code. In the maintenance process, whenever new features are added to the Spaghetti Code code base, we have to do not modify the Spaghetti Code simply by adding code in a similar style to minimally meet the new requirement. The more tightly integrated individual parts of the application are, the more indistinguishable there are from each other. Tight coupling prevent code reusability and leads to duplication.
Who use it ?
This is Pattern demonstrated by people new to object-oriented development, with lake experience in software architecture, who map system requirements directly to functions, using objects as a place to group related functions. Each function contains an entire process flow that completely implements a particular task.
Solution : Lasagna Pattern - Layered architecture - Divide and conquer (derived from the Latin saying Divide et impera)
When we start thinking to divide our project in layers, we should start from the project, and we have to ask about the best way to support such operational requirements as maintainability, reusability, scalability, robustness, and security, it's important to reconcile the following forces within the context of current environment that will be used. Every developer should think in Separation of concerns among components such as separating of the user interface from the business logic, and separating of the business logic from the database, and this will increases flexibility, maintainability, and scalability, the reuse of components by multiple applications. 
Separate the components of your solution into layers :
The best way in layered approach constraints components in one layer to interact only with peers and with the layer directly below. A relaxed layered application loosens the constraints such that a component can interact with components from any lower layer. Layers work together to produce the completed application, group of code working together as a common concern.
Let's revisits the classic 3-tier architecture
 
Presentation Layer : it contains the user oriented functionality responsible for managing user interaction with the system, and generally consists of components that provide a common bridge into the core business logic encapsulated in the business layer.
Business Layer : it implements the business logic of the solution and the core functionality of the system, and encapsulates the relevant business logic. It generally consists of components, some of which may expose service interfaces that other callers can use.
Data access Layer :  it encapsulates the code that accesses the persistent data stores such as a relational database, it provides access to data hosted within the boundaries of the system, and data exposed by other networked systems; perhaps accessed through services. The data layer exposes generic interfaces that the components in the business layer can consume.
Designing for scalability
Scalability is the capability if a system to handle a growing amount of work. Although usage is minimal during site development, usage can increase greatly after implementation to a production. To ensure a positive user experience, you need to consider scalability early in the application planning phase because your scalability decisions affect the architecture design considerations.
Move to n-tier architecture (.NET implementation)
"ASP.NET MVC framework provides a certain level of separation of concerns by breaking the application responsibilities down into models, views and controllers."
Business Layer can be divided to : Domain layer and Application layer.
Domain layer : will contain models and services, application layer will interacts with presentation and domain layers.

Infrastructure layer will contain IoC, cache and repositories, these components will be used by Business layer.
Business Logic—Domain-driven design Definition
Application layer : this layer will depend on use-cases : Data transfer objects, Application services that will call only methods implemented in Domain Layer.
Domain Layer : this layer will contain domain model (object-oriented entity, model functional model)  and domain services that is the implementation of every treatment so it's invariant to use-cases.
Go further : next post !

0 commentaires:

Enregistrer un commentaire