n-tier-architecture | 易学教程

Where to put sql when using dapper?

阅读更多关于 Where to put sql when using dapper?

问题 I'm using dapper for a mvc3 project at work, and I like it. However, how are you supposed to layer the application when using dapper? Currently I just have all my sql stuffed directly in the controller ( slap ) but I was thinking of making a class with static strings.. So I could do var reports = Dapper.Query<Report>(conn, MySql.ReportsRunningQuery) How do you store your sql when using dapper? 回答1: I would say put the sql where you would have put the equivalent LINQ query, or the sql for

Which layer should scheduled task be put?

阅读更多关于 Which layer should scheduled task be put?

问题 I'm trying to implement DDD application with layered architecture. I have: Infrastructure layer - a layer which implements technology specific parts of the application. Domain layer - a layer which contains domain model. Application layer - a layer which contains interferences to interact with domain model. And interfaces layer - a layer which receives events from the outside. The classic 3 layer (+ infrastructure) architecture is quite clear. But my application isn't very classic. Beside UI

Approaches for Error Code/Message Management in .NET

阅读更多关于 Approaches for Error Code/Message Management in .NET

问题 Looking for suggestions/best practices on managing error codes and messages in a multi-tiered applications. Specifically things like: Where should error codes be defined? Enum? Class? How are error messages or further details associated with the error codes? resource files? attributes on enum values, etc.? If you have a multi-tier application consisting of DAL, BLL, UI, and Common projects for example, should there be a single giant list of codes for all tiers, or are the codes extensible by

What to put in Business Logic Layer? [closed]

阅读更多关于 What to put in Business Logic Layer? [closed]

Closed . This question needs to be more focused . It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post . Closed 5 years ago . I have read lots of articles and they seem to vary from one author/developer to the next. In my situation, I am thinking about this setup for testing a project: Presentation Layer via ASP.NET MVC Service Layer (my plan is ASP.NET MVC Web API; this is on separate assembly) Business Logic Layer DAL using EF Some articles said I should not put CRUD operations on BLL and BLL should

Does three-tier architecture ever work?

阅读更多关于 Does three-tier architecture ever work?

问题 We are building three-tier architectures for over a decade now. Dividing presentation-, logic- and data-tier is supposed to allow us to exchange each layer individually, should the need ever arise, be it through changed requirements or new technologies. I have never seen it working in practice... Mostly because (at least) one of the following reasons: The three tiers concept was only visible in the source code (e.g. package naming in Java) which was then deployed as one, tied together package

API Design: Expose XML or Objects #2

阅读更多关于 API Design: Expose XML or Objects #2

I recently asked this question: Expose XML or Objects - thanks all for the responses. One point to clarify. The API will always be accessed remotely (i.e. as a service), most probably via webservices or WCF. I agree that in theory a strongly typed API exposing objects as the inputs/outputs is the right way to go. However, I feel that there is still an argument to be made for exposing XML. As I see it the reasons for using XML are: The business rules can be written by business analysts in Schematron. The interface is weakly typed, but as soon as it is called the data can be validated against

EF N-Tier Architecture [closed]

阅读更多关于 EF N-Tier Architecture [closed]

问题 Closed. This question is off-topic. It is not currently accepting answers. Want to improve this question? Update the question so it's on-topic for Stack Overflow. Closed 4 years ago . Introduction We require to build a n-tier application, as we would like to share our BL over multiple platforms and only write our DAL once. I've already done some research on this subject. As can be read here in Davide Piras's post: MVC3 and Entity Framework each VS solution must at least have 4 layers. So far

Layered architecture and persistence annotations on the model beans?

阅读更多关于 Layered architecture and persistence annotations on the model beans?

问题 I would like to follow the separation of concerns design principle in a new Java EE web app. If I understand correctly, this means that I have to keep the technical choices of my DAL (Data Access Layer) invisible from my model/business layer. As I use Spring Data Neo4j, I must annotate my model beans with e.g. "@NodeEntity", an annotation which is specific to Spring Data Neo4J. This seems to mix the model layer with the Data Access Layer. Is this a good analysis I'm doing here? If so, how can

Developing N-Tier App. In what direction?

阅读更多关于 Developing N-Tier App. In what direction?

Assuming the you are implementing a user story that requires changes in all layers from UI (or service facade) to DB. In what direction do you move? From UI to Business Layer to Repository to DB? From DB to Repository to Business Layer to UI? It depends. (On what ?) The best answer I've seen to this sort of question was supplied by the Atomic Object guys and their Presenter First pattern. Basically it is an implementation of the MVP pattern, in which (as the name suggests) you start working from the Presenter. This provides you with a very light-weight object (since the presenter is basically

Build enterprise application without service layer

阅读更多关于 Build enterprise application without service layer

There are so many tutorials that teach us to use for example some ORM directly with database, but in real life i cant remember a big project that was working directly with database and not with services, so the amount of that tutorials seems strange to me. Directly connected applications have real benefits in speed of data transitions between database and the app, and they do not have restrictions in functionality that appear because of service layers(for example lets take Entity framework and WCF Data services(that uses same entity data model itself)). On the other side services solution is