n-tier-architecture

Can the domain model and the repositories be in separate dlls? In a 3 tier architecture I guess I would put the domain model in the business layer and the repositories in the data access layer. I get confused as it is my understanding that the domain model uses the repositories while the repositories should return objects from the domain model, which would cause a circular dependency. I must be misunderstanding one or more of the above concepts. Any clarification would be greatly appreciated as this has been bothering me for a while, thanks. I don't think you should let your domain assembly

I am about to create a Desktop App (with .NET windows forms) Essentially, I want to create an n-tier app but I also want loose coupling between layers. However, I am not very sure if this is a good approach for windows forms And now I just wonder if it would be really a wise choice to use any IoC (StructureMap, Ninject, Spring.Net), I have used them before for Asp.Net web applications but what makes me doubt now is the fact that working with windows forms my business entities will persist when I navigate through tabs and unlike than web forms or mvc apps where it would be necesary to inject my

I'm looking to detect local connection loss. Is there a mean to do that, as with the events on the Corelabs components ? Thanks EDIT: Sorry, I'm going to try to be more specific: I'm currently designing a prototype using datasnap 2009. So I've got a thin client, a stateless server app and a database server. What I would be able to do is to detect and handle connection loss (internet connectivity) between the client and the server app to handle it appropriately, ie: Display an informative error message to the user or to detect a server shutdown to silently redirect on another app server. In 2

Our customer would like to know who is online and currently using the custom application we wrote for them. I discussed it with them and this does not need to be exact , more of a guestimate will work. So my thought is a 15 minute time interval to determine user activity. Some ideas I have for doing this are as follows: Stamp their user record with a date and time of their last activity every time they do something that hits the database, or requests a web page ... this though could be quite database intensive. Send out a "who is online request" from our software, looking for responses, this

Background I'm trying to create a simple application to really understand the whole stack of DDD+TDD+etc. My goal is to dynamically inject the DAL repository classes at runtime. This keeps my Domain and Application Services layers testable. I plan on using "poor man's DI" to accomplish this for now ... so I would do this in a simple Console application near startup: // Poor man's DI, injecting DAL repository classes at runtime var productRepository = new SimpleOrder.Repository.ProductRespository(); var customerRepository = new SimpleOrder.Repository.CustomerRepository(); var orderRepository =

Really impressed with Juile Lerman's pluralsight course on "EF in Enterprise" and decided to build my demo app. I am using VS 2012 and latest versions of EF,SQL Server and MVC. I am building a demo application which applies SOLID principles. I am doing this to better understand how to implement DI & unit testing. I have used DB first approach for this demo application. It contains only one table named UserDetails and below is how it looks in SQL server. I will use this table for CRUD operations. Below is how i have layered my application : 1. WESModel Solution: This layer contains my Model1

In a traditional sense, N-tier means separating the application into "tiers" and putting each "tier" on different servers. This was done for at least 3 reasons: Maintenance: a) Code Maintenance: Easier to do bug fixes and feature additions. b) Hardware Maintenance: Taking one server down does not disrupt service from other tier. Performance: One server was often not fast enough to handle web requests, business logic computations, and database/file access at the same time. Scalability: Specifically horizontal scalability a) Fault Tolerance: Ability to have more than 1 physical server per tier