Which design pattern to choose?

Question

I am engaged in the development of a small client-server application. I use multilayer architecture. At the moment, finished the implementation of the data access layer, while developing this layer, used the Repository pattern. Now I have a kind of gateway (interface class), with which the business logic layer can receive all the necessary data from the database.

Advise which patterns should be used in the business logic layer to then implement, say, the service layer. What are the options?

Correct me if I misunderstand something, or the question is asked incorrectly. Thank.

You do not think that they will say something like this: “oh, man, since you wrote a data layer using the Repository, then in the business logic you should definitely use abstract factories and facades”?
@ klutch1991 and for the rest - putters are solutions to problems.
Describe the problem you are facing right now - and they will tell you how to solve it.
You can only advise 3-Layer + IoC + MVC (now everyone is doing this), and even the samopisny repository that you screwed up is in doubt.
What is your standard implementation of the Repository + Unit Of Work + Query Object + Mapper in the context of the EF did not suit?

Accepted Answer · 2015-12-22T10:55:45

In the service layer (business logic layer), you can use many patterns, like OO patterns, and other patterns of a narrower or wider profile. It all depends on what your tasks in this layer are found. It is impossible to give a general ready-made list of templates, so, they say, use this and you will be happy. Not-can-but. And do not.

Forget about patterns for a while. They are not an end in themselves. First, do what you think is right. And at some point some tasks will seem familiar and you can solve them if you wish, by applying one or another pattern.

Even better, forget about the patterns for a year. And return to them after you get a little more experience. Then, I assure you, you will look at them in a completely different way, and moreover, you will even realize that you used some of them without realizing it. After analyzing your experience, you will understand where one or another template could be applied. Once again, you misunderstand why you need patterns, if you start from them. Patterns are not an end in themselves, but only a means. It's like asking "I want to build a house, what kind of brick should I take?". You do not start with the builder!

“It’s impossible to give a general ready-made list” - this is true, but the author of the question asked, “What are the options?”.
probably it is necessary to add in response to a couple of options that show the direction.
otherwise the author of the question risks both a year and two walking in a circle, since
The author has a small porridge regarding the goals and purposes of the patterns, so it’s simply no sense to give a list.
Patterns were born as a systematization of accumulated knowledge.
And in their study and application it is better to follow the same path - first accumulate experience and then systematize it.
“Patterns were born as a systematization of accumulated knowledge” - yes, but I’m not talking about all patterns at all, but about those that are actually used, for example, MVVM.
Or do you think some patterns are exclusively the fantasies of the authors, not related to reality?
“so I’m talking about the ones that are actually used. ... there are 30 variants” , the author asks about the architectural pattern, since
In such a situation, in practice, not 30 pieces of some patterns are used.
you probably know better than me what is used in .NET applications, so I suggested to designate the direction in which the author needs to “dig”.
it follows from your answer - that the author must wander for a year in the dark and ponabit bumps)

Answer 2 · 2015-12-22T10:51:24

If the business logic is unchanged part of the program, and the implementation of services may change, in such a situation, services must be defined as interfaces, and implement them in classes. In this case, only the service interface is transferred to the business logic, and the classes themselves (that is, the interface implementation) must be inaccessible from the business logic.

This allows you to change the implementation of services without changing the business logic. For example, they used a logging service that output data to a file, and later decided to output data to a cloud service. To do this, you need to replace only the implementation of the service, and the business logic remains unchanged.

Such a pattern is called "Strategy" - this is the isolation of the variable part through the interface.

Dependency injection (DI) is used to transfer service interfaces to business logic. For dependency injection, different methods and whole frameworks are used, for example, MEF.

It should be resorted to when working with unknown types or plugins.
For DI it is better to use the same autofac \ ninject and so on.
In general, with proper architecture design, even the injector must be replaceable.
@Bezarius "MEF for DI - nailing with a microscope" - do you know the size and other conditions of the problem?
it's not about the conditions or specifically about the project, but about implementing DI using MEF.
This option, let's say, is somewhat specific and is not a contender for universality.
If you offered the same autofack, which has integration with MEF (by the way, think about this fact), I would not say a word to you.
And so, I have a suspicion that you are not too well versed in the issue.
@Bezarius "If you offered the same autofack, ... I would not say a word to you."
- if you are satisfied with autofack, this does not mean that it is suitable for everyone.
and when they say "for example ...", it means that there are several options.

Which design pattern to choose?

2 answers 2

More articles: