Hot answers tagged

375

In order to define what a service's responsibilities are, you first need to define what a service is. Service is not a canonical or generic software term. In fact, the suffix Service on a class name is a lot like the much-maligned Manager: It tells you almost nothing about what the object actually does. In reality, what a service ought to do is highly ...


122

Layers, modules, indeed architecture itself, are means of making computer programs easier to understand by humans. The numerically optimal method of solving a problem is almost always an unholy tangled mess of non-modular, self-referencing or even self-modifying code - whether it's heavily optimized assembler code in embedded systems with crippling memory ...


62

The fundamental motivation is this: You want to be able to rip an entire layer out and substitute a completely different (rewritten) one, and NOBODY SHOULD (BE ABLE TO) NOTICE THE DIFFERENCE. The most obvious example is ripping the bottom layer out and substituting a different one. This is what you do when you develop the upper layer(s) against a ...


52

In my opinion, that's absolutely not how it's meant. And it's a violation of DRY. The idea is that the entity / domain object in the middle is modeled to represent the domain as good and as convenient as possible. It is in the center of everything and everything can depend on it since the domain itself doesn't change most of the time. If your database on ...


40

As for your title, I don't think the question makes sense. The MVC Model consists of data and business logic. To say logic should be in the Service and not the Model is like saying, "The passenger should sit in the seat, not in the car". Then again, the term "Model" is an overloaded term. Perhaps you didn't mean MVC Model but you meant model in the ...


33

Your colleagues are conflating architecture with implementation. The idea behind a multi-tiered application is simply that it's broken up into parts that encapsulate certain kinds of processing (storage, business logic, presentation) and communicate with each other using well-defined interfaces. Just as it's possible to successfully do things that resemble ...


25

I'm working on the greenfield project right now and we had to make few architectural decisions just yesterday. Funnily enough I had to revisit few chapters of 'Patterns of Enterprise Application Architecture'. This is what we came up with: Data layer. Queries and updates database. The layer is exposed through injectable repositories. Domain layer. This is ...


22

The "layers" that we describe when we describe software systems are abstract concepts. To the computer, all it gets to see is a featureless stream of one opcode after another, no matter which layer, which class or which method it originally came from. In this sense, they are not "real" at all. However, layers (and classes and methods) are useful for ...


20

Android does not play as nicely with other frameworks as it could. Its recommended style of development assumes you build everything from its API, without other libraries. The UI layer is very tightly coupled to the model. This style is ideal for writing smaller, modular apps, not for complex applications. You need to give some thought as to whether you ...


19

Stored procedures are powerful enough to let you code a violation of three-tier separation by bringing business logic into the RDBMS layer. However, this is your decision, not an inherent flaw of stored procedures. You can limit your SPs to servicing the needs of your data layer, while keeping your application logic in the application layer of your ...


14

I am comfortable to say that an object belonging to a layer can depend on objects from lower layers To be honest, I don't think you should be comfortable with that. When dealing with anything but a trivial system, I'd aim to ensure all layers only ever depend on abstractions from other layers; both lower and higher. So for example, Obj 1 should not depend ...


13

The example you provide is hardly layered architecture. I know it is intentionally simplified, but: Your presentation layer is directly tied to the Person entity. This is OK only in simplest cases, and definitely not when you are trying to define your layers. The GetPerson method is also using a rather bad practice of creating a new context for each call. ...


12

If you have just finished your application then you have not seen the benefits of this approach. You will find most of the benefit of doing this as you begin to make changes to the existing application. Think about how easy it will be to move items around in the UI as you change the application. Or how easy it will be to performance tune a specific portion ...


12

A UoW might involve one ore more aggregated roots and repositories. No, absolutely not. That misses the entire point. We always change one aggregate at a time (one per transaction). Transactions are typically coordination between the application component and the persistence component. The application starts a transaction (UoW, if you like), reads the ...


10

If your application does indeed have these separate layers (I am assuming UI, BLL and DAL), then: You can write other UIs (desktop, mobile) without changes to other layers You can make changes to your BLL and not effect the UI or DAL (and with several different UIs the changes will just happen automatically) You can migrate to a different data store without ...


10

There is a big difference between the application layer and the presentation layer from a DDD view point. Although DDD centers around how to model the domain using the DDD building blocks and concepts such as bounded contexts, Ubiquitous language and so, it is still vital to clearly identify and separate the various layers in your app. The architecture ...


10

Often an abstraction layer is commonly used to 'abstract' away detail. Say you had a program for moving money around between different banks. There is a function for moving money to BankA, and a different function for moving money to BankB and so on. The different functions might exist because the information that different banks request varies (As a ...


10

Layers, Onions, Ports, Adapters: it's all the same Since this article makes clear that onion is equivalent to 3 layer + application of the Dependency Inversion Principle (DIP), then the question becomes "where should I prefer to use DIP?" I'd say any non-toy project. Using DIP allows the core of your code to be more isolated, testable and maintainable. When ...


10

Yes, objects in one layer can have direct dependencies among each other, sometimes even cyclic ones - that is actually what makes the core difference to the allowed dependencies between objects in different layers, where either no direct dependencies are allowed, or just a strict dependency direction . However, that does not mean they should have such ...


9

This is one of those things that really depends on the use case. The overall point of a service layer is to consolidate business logic together. This means that several controllers can call the same UserService.MakeHimPay() without actually caring about how the payment is done. What goes on in the service may be as simple as modifying an object property or ...


8

The easiest way to illustrate why programmers shy away from putting domain logic in the domain objects is that they're usually faced with a situation of "where do I put the validation logic?" Take this domain object for instance: public class MyEntity { private int someProperty = 0; public int SomeProperty { get { return this....


8

There are two facets to this problem and both should be satisfied for a good application to work: Fail Fast - having the user fill all the data, press the action button, wait 5 seconds, only to fail since some text at the beginning of the form should be at least 3 characters, or a dash has been forgotten is a very bad experience - do your security and ...


8

In the MVC design pattern, the Controller part is responsible for translating user actions into modifications of the various Model classes that are involved in a piece of functionality. There is no one-to-one relation between Controllers, Views and Models. In particular, if a user action requires changes to multiple Model classes, then it is the ...


8

It sounds like you're describing the onion architecture, a form of n-tier architecture -- which is just a fancy way of saying it has components broken out into layers. The layer you're focusing on is the Infrastructure layer. Data is the most common component of infrastructure. But other functions can be contained in separate libraries in the same layer. ...


7

It is pretty common in PHP Projects to have some kind of Data Abstraction or Data Access Layer. Simply because of DRY Principles and cleaner error handling. Experienced Programmers don't like to repeat themselves over and over again and they seperate domain logic from data manipulation as much as possible. There are lots of very good Frameworks and ...


7

Just because someone created and named "Application Layer" and "Presentation Layer" doesn't mean your application should have them. You should create layers AFTER you created substantial amount of code which you grouped together and want to name this group for sake of communication between developers and clarity of code. From point of DDD. Application Layer ...


7

I think the answer is clear if you read Martin Fowler's Anemic Domain Model article. Removing the business logic, which is the domain, from the domain model is essentially breaking object oriented design. Let's review the most basic object oriented concept: An object encapsulates data and operations. For instance, closing an account is an operation that an ...


7

So besides adding the code for getting screws, I had to modify 4 lines. This would increase linearly with the amount of layers. I think this is a fallacy. When you add another kind of table part, you will still have only to change 4 lines of code in your "object construction layer". The layers above the "object construction" layer in your code will just ...


7

You actually got it right. And there is no violation of DRY because you accept SRP. For example: You have a business-Method createX(String name) then you may have a Method createX(String name) in the DAO-Layer, called within the business-Method. They may have the same signature and maybe there is only a delegation but they have different purposes. You can ...


Only top voted, non community-wiki answers of a minimum length are eligible