Tag Info

Hot answers tagged

21

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


15

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

I think the word 'service' gets bandied around so much that it's meaning nowadays is very overloaded and confusing. There is a big difference between a 'service layer' and a 'web service [layer]'. A 'service layer' is an abstraction behind which you put the business logic that will be consumed regardless of the UI. That way the UI layer can be as simple ...


10

You've got a lot of moving parts in your question, touching on a lot of concepts, but here's my basic advice when it comes to how to think about a mid-to-large scale MVC application: Presentation <---> Business Logic <---> Data Access Firstly, it's best to not think of the the app as "an MVC application". It's an application that uses the MVC pattern ...


9

Its difficult to see with this example because the program is almost entirely trivial, however your supervisor is pointing out the fact that the Main method contains the core application logic (i.e. it defines how the application fundamentally behaves). Why is this a bad thing? Well in this example its not really as the program is very simple (which is ...


9

The definition of 3-tier architecture is a special case of the n-tier architecture. In an n-tier architecture, there are n components and each one only interacts with the component immediately "above" and "below" it. A three-tier architecture has three such components. Typically, a three-tier architecture consists of a user interaction layer, the business ...


8

A typical multi-tier application looks like this: In an MVC application, the data tier and logic tier reside in the Model, while the presentation tier resides in the View. In between the Model and the View, the Controller provides a switchyard, routing web requests and responses to the appropriate methods, views and model logic. Within the Model, you ...


7

The way you are doing DI is wrong. First, the connection string belongs in the data layer. Or in the web.config file. The next abstraction you will be dealing with is the DbContext, not a connection string. Your repositories should not know about connection strings. Your business logic will not know about DbContext etc. Your UI will have no idea and will ...


6

In an ideal (service oriented multi-tier) world UI should communicate to a business layer through data contracts and a service facade. The UI should not need to know anything about the actual business layer or the entities and methods the business layer works with. So a UI and service facade would share a data contract definition (these can be simple ...


6

WCF can be used as one of the tiers. I suppose the whole point is that, if you create your service tier using WCF, you can re-use it with other tiers. For example, you can have a web page and a WPF application that both display data from the same WCF service.


6

It sounds as if your friend was in a very common trap for programmers: His employer needs an expert for the kind of code he has right now. As the code he has now becomes more and more outdated, finding experts for that kind of code is getting harder and harder. So he's paying your friend a high salary to keep him from leaving and to keep him from learning ...


6

You are correct that dependency injection solves this problem cleanly. However you don't need to necessarily know what that is or have a framework to solve this problem. What you need is a way to register an implementation of INotify as an available implementation to use. (Register where, you say? I say, "somewhere, anywhere, whatever makes sense.") And ...


5

This is a common scenario so I will try to answer it in a reusable way. The issues with static classes are: they make testing difficult (due to their ability to hold state across tests) they cannot be swapped out with an isolated test-specific version they make it difficult to swap out the default implementation with a different one (note this is the same ...


5

This is not a complete answer but it addresses one important point. Namely the difference between layers and tiers. "It is important to understand the distinction between layers and tiers. Layers describe the logical groupings of the functionality and components in an application; whereas tiers describe the physical distribution of the functionality and ...


5

Quoting Martin Fowler's famous article: In MVC, the domain element is referred to as the model. Model objects are completely ignorant of the UI. So the answer is, the "Business Logic" clasically belongs in the model layer. (Which, itself can consist of arbitrarily more stuff, definitely not just anemic domain objects). You putting your domain objects ...


5

If the UI layer has no access to the assemblies or authentication information needed to access the database, it is impossible to access the database directly from that layer. If you have separated your layers into separate assemblies, and limit the public data types and members to only those needed in the higher level layer, it is easy to detect a violation, ...


4

First of all, there isn't really much of a comparison. The current architecture obviously grew as bits where added, and your approach is a re-design, the obvious advantage being you know exactly what the layers are and how individual components interact. It's obviously the better approach, you are introducing a middle service layer that essentially makes the ...


4

How does the presentation layer trigger database changes? Well, presentation layer should not directly trigger changes in database layer. It should initiate call to the service layer, where your business logic should verify the request. Upon successful verification it should perform DB operation on entities/tables that it needs. You may also look at ...


3

A few quick comments. I personally probably wouldn't pass a connection string. If anything I would try and create interfaces maybe for the repositories and just pass the interfaces around? Have the repositories implement or expose a IOW interface. This way it doesn't event need to be a database that implements your repositories. they could be an in ...


3

The main argument against "self-tracking entities" (or the ActiveRecord pattern, as I've heard it called) is that it mixes persistence logic into your domain model. The POCO alternative gives you better separation of concerns. Consider the case where you might have your model operating in a client or server environment. You could abstract your persistence ...


3

The benefit of an application service (doesn't have to be a web service) over a dll is you can off-load the execution of the service on a separate machine (probably a server). In the case of your UI being a desktop app, the local machine doesn't need to have as much code installed nor does it need as much horsepower to run your app. A website could still ...


3

Brief Summary: It really depends on your usage of stored procedures and business requirements. There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier. Speaking about terminology, in general words these tiers described as: The ...


3

N-Tier is not necessarily on different networks. Each tier is in a separate process, it could all be on one machine. 3 tier is somewhat out of fashion due to the out of process marshaling it requires. Any extra tier, read: process boundary or worst communication across a network transport, is expensive. In a 3-tier system the second tier is usually the ...


3

Both concepts introduce a separation of concerns. But for layers, seperation of concerns is usually the main goal. Tiers are used for scalability and load distribution/allocation purposes, and separation of concerns is more a side effect there. That also explains why the concepts are not easily translatable. In a layered architecture, a feature is usually ...


3

The words "disconnected context" refer to the fact that most modern web applications only connect to the database long enough to retrieve and store data for the lifetime of a single web page. While they might maintain a session, they do not typically maintain a persistent database connection like a client/server application does. Basically what they are ...


2

Hmm, your INotify is at the model layer but the functionality you need for a particular implementation of it is in a layer higher up. There is nothing preventing you from creating a class implementing the interfaces of your notification system in that layer (DAL or even BAL) while still having the mechanics declared in the model layer. Just be watchful not ...


2

If he's happy with what he's doing and has a stable income, there's no reason for him to change. Even today there are COBOL programmers with a steady income. If the platform is big enough, it'll probably be around until he decides to retire. The catch is that he'll have to work with the same platform and type of problem until then. If he wants to do ...


2

What benefit will he see from those methodologies? With that kind of attitude, they will see very little benefit. He has worked for a decade without unit-testing, uses code-behind and structure programming and it works for him They're simply resisting change. It is just a way to avoid learning. Many, many changes will make someone better. ...


2

There is a peice of information you are missing. Your UI layer is simply the Console object. The UI layer is the mediator between the user and the computer. With Console, you only have the abilty to write stuff to the console, and read input from the console. So your UI layer is very simple. The application however, also needs a controller. The controller, ...



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