Tag Info

Hot answers tagged

117

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

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 ...


61

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 ...


26

Building fast GUI prototypes is a good idea, and I have heard it being used in many projects. Early feedback is valuable indeed. However, it has its dangers: it is very tempting (for managers / users) to use the prototype code further and build the final application on it, which can have very bad long term consequences (this actually happened in one of the ...


21

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

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 ...


14

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 ...


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 ...


11

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 ...


9

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 ...


8

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 ...


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 ...


7

Yes. And also assemblies. I'd separate by layers, then components. Yes. There are different approaches to this, but I'd have an IDatabaseService (abstracting the various manners in which the database is called -- this can almost be a direct mapping of the ExecuteScalar/ExecuteNonQuery/ExecuteReader), and then various data access classes that partition by ...


7

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. ...


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 ...


6

This is reasonable - as a customer you can require anything you want, and using good layering as an indication of code quality and separation of concerns is a valid requirement. There are many tools out there that will help with such documentation - some of them will produce an image of the Directed Acyclic Graph, showing you that the lower down layers are ...


6

While it is true, that the standard enterprise architecture is pretty close to the three-layer model, truth to be said, it actually means harder maintenance. If you grab an SVN/CVS/git/... log of an enterprise application with considerable history, you'll find out, that the rate of change is as follows: views change all the time models change about as ...


6

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 ...


6

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 ...


5

Good question. Here is a C#-ish code that lets you have it both ways. The trick here is lazy evaluation (yield). // Lazy producer that will auto-close the file. // The OS and the disk do the caching for you. public static IEnumerable<FooBar> GetFoobars(string fileName, long maxNumber = 1000000000000) { using(File file = open(fileName)) // ...


4

Layers for the sake of having layers is a common problem. I've seen a number of services and applications that were technically n-tier but were very guilty of violating principles like DRY, separation of concerns and the like. For example, I've worked with apps that had upwards of 10 object creation steps between the UI and the DB, 30+ different DLLs with ...


4

It depends on what you do with your data model. If you have existing code that manipulates an object oriented model, and if you want to persist those objects in a sqlite database, you need an orm. If you are writing new Android code from scratch, I would avoid an in-memory data model unless the app performs really complex OO manipulations, as a CAD program ...


4

I think @Péter is right to suggest that building GUI prototypes is a good idea. I'd like to supplement with the potential pitfalls of providing the user experience in an ass-backwards manner, that is, focusing on ontologies, the architecture and the infrastructure first and the immediate user experience last: The user that you've pushed to far end of the ...


4

Regardless of the structure you choose, the quality of the communication within the team is possibly the most critical factor to your success (assuming of course that the developers have good enough skills). I am currently working in a project team of 20 developers, for a large layered application. I manage 9 and my colleague manages 9, while we jointly ...


4

I think that the main reason is that it makes things more tightly coupled. The tighter the coupling the more likely to run into issues later. See this article more info: Coupling Here is an excerpt: Disadvantages Tightly coupled systems tend to exhibit the following developmental characteristics, which are often seen as disadvantages: A change ...


4

IMO, it's very simple. You can't re-use something that keeps referencing the context it's used in.


4

Layers should not have two-way dependencies The advantages of a layered architecture are that the layers should be usable independently: you should be able to build a different presentation layer in addition to the first one without changing the lower layer (e.g. build an API layer in addition to an existing web interface) you should be able to refactor ...


4

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 ...


4

Layered Architecture speaks to the flow of business-related data between layers. It has nothing to say about utility libraries; every layer can potentially access a given utility library, just like you have done.



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