n-tier-architecture

I've read conflicting philosophies on where data validation should happen and it's just confusing me more. Some say it should only be in the database. Others say that the validation rules should be mirrored in other layers like the bll or ui. Where should the data validation live? Should rules be split across multiple layers? What are some of the actual best practices (as opposed to theory, head in the clouds type stuff) regarding when and where to validate data in an application running on top of a database. My 2 cents: Data validation should occur in two locations: The point where data is

What are some questions I can ask myself about our design to identify if we should use DTOs or Self-Tracking Entities in our application? Here's some things I know of to take into consideration: We have a standard n-tier application with a WPF/MVVM client, WCF server, and MS SQL Database. Users can define their own interface, so the data needed from the WCF service changes based on what interface the user has defined for themselves Models are used on both the client-side and server-side for validation. We would not be binding directly to the DTO or STE Some Models contain properties that get

Usually when i layout an n-tier architecture for a project I have the following layers: Domain (domain model, repository contracts) Data (repositories working on top of domain model) Service (aggregates repos, caching, validation) Presentation (the mvc app) Where would ASP.NET MVC 4 Web API fit into this considering that it will be used by the actual application and outside clients? Is it part of the service layer or does it use the service layer and sits at the same level with the MVC app? There could be 2 approaches: You decide to consume your Web API from the MVC application through HTTP

I've been trying to figure this out for days but there seems to be very little info on this particular subject with ASP.NET MVC. I've been Googling around for days and haven't really been able to figure anything out about this particular issue. I've got a 3 layer project. Business, DAL and UI/Web layer. In the DAL is dbcontext, repository and unit of work. In the business layer is a domain layer with all the interfaces and the EF models. In the business layer there is also a service layer with DTOs for the EF models and a generic repository service that accesses the repository. This picture

What is the suggested approach or best practice for handling exceptions in tiered applications? Where should you place try/catch blocks? Where should you implement logging? Is there a suggested pattern for managing exceptions in n-tiered applications? Consider a simple example. Suppose you have a UI, that calls a business layer, that calls a data layer: //UI protected void ButtonClick_GetObject(object sender, EventArgs e) { try { MyObj obj = Business.GetObj(); } catch (Exception ex) { Logger.Log(ex); //should the logging happen here, or at source? MessageBox.Show("An error occurred"); } } /

This seems like it should be an obvious question, but I have had some issues finding a good answer. I am building an n-tier application that needs to be UTC time sensitive. Values can be updated and when they are timestamps are recorded. This includes transactions in the database where updates or inserts will impact datetime columns. To give some context I am using SQL 2008 R2 + with DATETIMEOFFSET(2) for most of my datetime columns. I am considering putting the updates for timestamps into the Stored Procedures so that they do not need to be passed through the network. This will save bandwidth

I saw this comment on MSDN ( link and link ): "Note that Independent Associations should often be avoided since things like N-Tier and concurrency becomes more difficult." I'm new to EF4 and I'm building an n-Tier web app. This sounds like an important pitfall. Can someone explain to me what this means? I think it's personal preference. Originally, EF was created to only use indep. associations and aligned with a more classic ERM approach. However, most of us devs are so dependent on FKs that it made life very complex. So MS gave us FKs in EF4 which meant not only having the FK as a property

I usually name by classes in the Business project as Manager.cs, like BaseManager.cs, CommentsManager.cs, ProfileManager.cs, etc... How do you name your classes in the DataAccess project? Do you call it CommentsDA, CommentsDB, or what? Just curious...BTW, I'm using .NET C#. John K Naming Conventions between Software Layers I used to separate class naming conventions for each kind of software layer like you're asking about. However in the .NET world upon realizing each layer is it's own assembly, and assemblies are often replaceable with assemblies implementing same interface/s, I found the