Architecture :: Should The Unit Of Work Point To The Service Layer Or The Repository And Then The Repository Point To The Service Layer
Jan 26, 2011
Just wondering, in an ASP.NET MVC3 environnement with entity framework. Should the Unit of Work point to the service layer or the repository (and then the repository point to the service layer) ?
Ive saw two example:
* One where the unit of work and repository both have an instance to the service layer..
Link: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable
Doesn't use a service layer but its obvious that one could be use in that case.
* Second where the unit of work have an instance to the repository which have an instance to the service layer..
In an ASP.NET MVC3 environnement with entity framework. Should the Unit of Work point to the service layer or the repository (and then the repository point to the service layer) ?
Ive saw two example:
* One where the unit of work and repository both have an instance to the service layer..
Link: Entity Framework 4 CTP 4 / CTP 5 Generic Repository Pattern and Unit Testable
Doesn't use a service layer but its obvious that one could be use in that case.
* Second where the unit of work have an instance to the repository which have an instance to the service layer..
My repositories throw exceptions (System.Exception) when some things go bad and I know this is bad practice.. so i will create a custom exception (DataException). My question is should this custom ex class be in the repository layer or the domain layer? Im thinking it should be in Domain layer where all business objects and repository interfaces live but just want to make sure.
I've been reading recently about EF4, and how to build an architecture for asp.net web forms application using it.
I explored using POCOs (self tracking entities), with WCF, but found out that my application will be deployed on a single box (i.e. one tier), so I started reading about logical separation of layers, and came up with the following solution:
DAL layer that contains EDMX model and EF APIs, and also generated context object.Entities DLL that holds all generated POCO entities using ADO.NET POCO entity generator. (for persistence ignorance, and decoupling entities from DAL).Business layer that contains a façade for each related group of business functions, the façade will be aware of and using DAL layer. And in each function, it will initiate context and uses different entities to carry out specific job (i.e. function).UI layer that only calls the business layer façade classes. With no awareness of DAL, but it will be aware of entities (i.e. using entities DLL), as the business layer will return results basically as entity collections.
I want to know what you think about this architecture.
I also read about an architecture that uses repository and unit of work patterns, but what I understand that context object is already implementing a UOF pattern, and also object sets are implementing repository pattern (correct me if I'm wrong), so the only advantage of using additional abstraction over them is to make the business layer communicates to my classes, not EF classes, and this is good only if the DAL strategy might change (i.e. by using another tool other than EF, which is not my plan).
I'm reading through Architecting Microsoft .Net Solutions for the Enterprise and I try to figure a couple of things out concerning the Presenter and the Service Layer.
First off, my Presenter needs to call methods that reside in the Service Layer, like initialize(), save() etc. But where do I place a reference to the service layer? Should it be at class level in the Presenter, or should I define a new service in the presenter methods itself?
Second - this isn't really clear in the book either - is this how the processing from the Presenter to the Service Layer works?:
We're building a large web app that has numerous layers. In order to communicate to the business layer we're using a service layer that the web layer calls when data is needed. Unfortunately, it seems that if exceptions are thrown in the business layer, it seems that the services on the web side are wrapping the exceptions and re-throwing them. We're looking for a clear way to encapsulate the error and log it, without WCF wrapping a new exception around the original.
I'm trying to reevaluate our n-layer architecture and would love to get some based on your experiences. Here is our typical .NET n-layer (sometimes n-tier) design.
DataAccess typically consists of Entity Framework 4 and Repository classes. I attempt to follow the Aggregate Root concept in order to avoid having a repository for table, easier said than done in my experience. I tend to have ~70% match between Repositories and Tables.
Model usually consists of my Entity Framework 4 entities, I've been using Self-Tracking EF entities with success.
Business is what I struggle with the most. I typically have a Manager class for every Repository. This class will contain methods like .Add() which will perform business validation before forwarding down to repository.Add().
Services, typically I will only implement this if in fact I am looking to create a web service based solution. This layer will be tasked with marshaling requests/responses between DTOs and entities. And most importantly provide the more coarse grained interface. For example a TradingService.SubmitTrade(), which is really a facade for a business transaction which might include AccountManager.ValidateCash(), OrderManager.SubmitOrder(), etc.
My business layer is very entity centric, really it's just the glue between the entities and the repository, with validation in between. I've seen many designs where the Service Layer is what holds a reference to the repositories (in essence skipping the "business layer"). In essence it serves the same purpose as my Business layer, it does the validation, however its' responsibility (and naming) is a higher level, more coarse grained business transaction. Using the example above the TradingService.submitTrade() will not delegate to any business manager classes, it would itself query the necessary repositories, perform all the validation etc.
I like my design in a sense that I can reuse a business layer method in multiple service calls, however I hate the fact that for every repository I have a matching business layer manager, creating tons of extra work. Maybe the solution is a different type of grouping at the Business Layer level? For example combine individual Manager classes like PhoneManager and EmailManager (note I have Phone entities and Email entities) into a logical Manager class such as ContactsManager (note I don't have a "Contact" entity type). With methods such as ContactManager.GetPhones() and ContactManager.GetEmail(), etc.
how to complete my implementation of the Repository pattern in an ASP.NET web application.
At the moment, I have a repository interface per domain class defining methods for e.g. loading and saving instances of that class.
Each repository interface is implemented by a class which does the NHibernate stuff. Castle Windsor sorts out the DI of the class into the interface according to web.config. An example of an implemented class is provided below:
[code].....
As pointed out in a previous thread, the repository class needs to accept an unit of work container (i.e. ISession) rather than instantiating it in every method.
I anticipate that the unit of work container will be created by each aspx page when needed (for example, in a property).
How do I then specify that this unit of work container instance is to be passed into the constructor of StoredWillRepository when Windsor is creating it for me?
i have created a normal web service and i want to host it outside IIS. one idea i got is to use window service as hosting environment. i have created a web service and hosted it window service and its window service is running now.would anybody please let me know that how can i call web service hosted in window service binded over soap.tcp. here is my sample code.
I am new to this .NET what is the difference between N-Tier and 3- Tier Architecture. If they are same. How to pass the values from presentation layer to business logic layer.
For Example
I have 10 controls in presentation layer. I passing values to these controls. How the architecture works.
i'm new to asp.net MVC, and I'm trying to understand the service/repository pattern and how to best implement it.
I've followed the MVC Music store tutorial, and it suggests that the public partial class ShoppingCart implements an AddToCart method looking like this:
[Code]....
Now if I would like to use the service/repository pattern in a correct way, should I just replace the row "storeDB.AddToCarts(cartItem)" with something like cartService.AddToCarts(cartItem) and then just save the added row by calling cartService.Save() instead of shopDB.Save()? The methods AddToCart(...) and Save() in cartService then calls the repository that does the actual saving.
I am building a web site following the tutorials on asp.net. I am using dataset as data access lay, and writing classes to access the dataset. But the example is just basic ideas, how do I retrieve individual table column value in the business layer?For example, if I have a table called Product, I only want to find out what is the product name by product id. I did this in my ProductBLL:
public ProductBLL { public int GetProductName(string productId) { ProductDataSet.ProductDataTable prodData = Adapter.GetProductById(productId); [code]...
Is there a better way, or am I doing this correctly? Can anybody give me a reference to a more complicated business logic model?
When I first heard about ASP.NET MVC, I was thinking that would mean applications with three parts: model, view, and controller.
Then I read NerdDinner and learned the ways of repositories and view-models. Next, I read this tutorial and soon became sold on the virtues of a service layer. Finally, I read the Fluent Validation documentation, and I'll be darned if I didn't end up writing a bunch of validators.
Tonight, I took a step back and thought about what had become of my project. It seems to have become the victim of the design pattern equivalent of "feature creep". Somehow I'd gone from Model-View-Controller to Model-Repository-Service-Validator-View-ViewModel-Controller. You want loosely coupled and DRY? We got your loosely coupled and DRY right here! But I'm wondering if this could be a case of too much of a good thing.
Am I right to be concerned? Or is this actually not as crazy as it sounds? On one hand, it seems crazy to have so many layers. On the other hand, every layer has a clearly defined purpose that makes sense to me. Have your MVC applications turned into MRSVVVMC apps too? If not, what do they look like? Where's that right balance?
here i have in 3-tier architecture , how to pass the data between DAL and BAL. i am using grid view to edit the data,when ever i click on the edit button all the corresponding fields should come to textboxes. i tried for delete ,it works fine bt not working to EDIT.
I was going through the MVC samples regarding validation at the service layer and I have a question and probably a dumb question at that. If you have the item below, the data is already in the product object and this is fine if you are expecting mappings with the correct data types, however presuming UnitsInStock is an Int, then if the user had typed in "banana," and considering that nothing has been validated on the server side at this point, then the app would have failed as soon as you tried to insert "banana" into UnitsInStock when the form returned from wherever at the controller layer.
protected bool ValidateProduct(Product productToValidate) { if (productToValidate.Name.Trim().Length == 0)[code]....
So my question is...is there a tricksy way (or best practice way) of dealing with this or do you have to use a "dirtyProduct" all strings object that you validate at the service layer and which returns a clean "Product" object if is "isValid" that can be passed into the repository?
I have been researching for a while and have actually created a prototype ASP.NET web service as a DAL for a few ASP.NET 2.0 web sites. Just would like to ask for some insight/advice from more experienced developers out there who had successfully rolled out DAL as a web service. What are the drawbacks/risks to deploying DAL as a web service? What is the best way to secure or authenticate consumption of this web service? WCF is out of the question, I'll be coding in VS 2005.
I'm creating a Asp.Net MVC application and I need help on whether I should chose Data Annotations or Service Layer Validation (e.g. if(Model.Name.Trim().Length == 0)?
I am working on Tenant module that has to display following fileds, Tenant Id, Tenant Desc, Contact Person, Contact Phone. In the DB, these are designed as two separate tables - Tenant and Contact. Tenant table has Tenant Id, tenant Desc and Contact Id . Contact table has all the contact related properties. I am using EF as DAL.
To make my system loosely coupled, I have created a repository pattern to talk to EF entities. Also, for validation I am using service layer.
My repository layer has two interfaces and classes corresponding to Tenant and Contact.
public interface ITenantRepository : IRepository<Tenant> // IRepository<T> is a generic interface for CRUD operations { Tenant Get(int id); IEnumerable<Tenanr> List() ;
We are designing a system that has functionality that is essentially the same at the presentation layer and the exposed API layer. My question is what technique / strategy to use so we can get the most reuse out of our code with performance in mind? Here's a simplified example: A user can add a Customer via a web form. This will fire the Customer.Create() method. An API consumer / user can add a Customer via a SOAP / HTTP-POST to a web service which will call the Customer.Create() method.
Imagine these layers: PRESENTATION | | WEB SERVICE API (Customer.Create() is available here | | FACADE Business Object Interface - Customer.Create() signature is here | | BUSINESS Business object - Customer.Create method() is fleshed out here | | DATA ACCESS - Writes data
The presentation layer SOAP calls the Create() web method, which calls the facade's Create() method which calls the business object's Create() method which wires via the data access layer.
Questions:
Is there a concern about performance in using the API's web services in our presentation layer, or are there alternatives to connect the presentation layer directly to the facade? If so, what technology to use (WCF, Remoting, Web Services, etc)?
We're doing a data integration project between a MS Sql Server database and a Microsoft CRM system (through its web services).
We're trying to build a "service" layer on top of the database. The design of our current solution is to use web services for CRUD, with xml being the format of data.
Views are created to consolidate related tables into one entity, and we query these views, using the "SELECT * FROM someview " + "For XML" to generated xml that will be returned from our web services.
For update we're trying to use the same approach - using SQL XML to map updates views, we have "instead of" triggers defined on top of these views, and in these "instead of" triggers we update the underlying tables.
The views/triggers are generated by tools so don't be too concerned with coding efficiency here...
what do you think if we use WCF data Provider to publish a enterprise data model (essentially DTOs) ? p.s., we don't have a BL layer for now, it's all in the stored procedures!!!
We are adding tooltips to our ASP.NET MVC product, and we are getting the text from our database (technically, from a cached copy of the data). To do so, we created an Html Helper method:
The GetTooltipText method is in our BaseViewModel, and simply uses the passed in Id to fetch the tooltip from cache. Would this be considered a bad design? What other alternatives would we have?
I have been looking at the unit testing topic and honestly I have never yet seen it in a live application.
Im a little foggy on the subject.... A simple example is if I am populating a listbox with data, I would know through debugging if the data is being populated and if it wasnt it would probably be easy to figure out why. Futhermore I couldnt possibly put it in production if it wasnt work so, why would I need to do a unit test? I dont see the point of it.
I need some guidance for an application I am working on. I have searched the web and the forum and found parts that answer my questions but I want to do this correctly. My solution uses LINQ to SQL to model the db and I have a repository that is querying my db everytime a controller needs to get some data for the view. I am initially anticipating a maximum of only about a few hundreds hits per day (if that). The website is a directory, with listings and requires a search functionality.
1. What options should I consider to avoid having my repository query the db everytime
2. The site contains a 'search' option, how can I implement this against my repository?
I guess I'm really looking for someone to point me in the right direction. So far I've looked at 'caching' the LINQ to SQL model and Lucene.NET but both seem overkill or am I missing the point?
