I'm Developing a website using asp.net and sql server i'm using EF with the code first approach as a Data access layer, and the business logic layer(BLL) i've developed a class for each entity that contains functions to query the data base and return object of this entity, my question is about the where i can implement functions that returns data from different tables not from only one table in the BLL.
DAO layer is supposed to create model objects from underlying datastore. In some cases, to create a particular model, different tables have to be queried. In this case, it will be the DAO that will interact with multiple tables (not the service).
BLL might deal with different models in the same service. However, it should depend on one DAO for one model.
In other words, DAOs are mapped to model classes not underlying tables.
Related
I using MS SQL Server with C# and Entity Framework.
The data-tier have one repository for every table that handle Save, Delete, Get etc.
Then i have a business layer that helps the user interface with data transactions and error handling and so on.
In one of the column in database i need to do a calculation before save.
Should i override the Add/Update method in the data-tier and do this calculation or should this be placed in business tier.
Thanks in advice.
In a fine grained, well scaled application design, respecting to standard specifications AKA SOA, any entity has its own service(business) layer and persist layer objects.
When User-interface layer calls a service, the service is receiving a simple or composite DTO that may be mapped to one or more separated database entities, it is allowed in service layer to call other entities service, and you are not allowed to call other entities persist layer objects.
Following the approach:
If the calculation of property A1 in entity A is based on properties of entity A then you may do the calculation on persist layer. If The calculation of property A1 in entity A is based on other entities properties then you have to do the calculation in service layer.
Assume you have a database where you store the information about a ticketing system (like helpdesk). The (simplified) schema is:
Ticket (TicketId(PK), TicketDesc, TicketCreated, TicketClosed,
AssignedToEmployee(FK))
Employee (EmployeeId(PK), EmployeeName, EmployeeFunction)
Where there is a one many relationship between Ticket and Employee on AssignedToEmployee = EmployeeId.
You have to develop an MVC application (DAL composed by EF entities + Repository class) that displays graphs and statistics about tickets, such as Number of Tickets Assigned to users in a specific time period. In order to calculate the statistics and provide the values for the graph to the View, you need to perform some logic.
This logic can be put in the Controller or in the Repository. Since the Controller has to be kept as slim as possible and the implementing logic within the Repository will increase coupling with the database, what is the best in this case?
Create a Service layer or create database views? In the latter case, the created views are to be considered entities within my EF?
I'd create a service layer. Controllers are really part of View, in my opinion. Repositories should not be doing calculations. You need the Service in-between. This arrangement will have a number of advantages:
Services can be reused by other apps in a SOA.
Services can be exposed using any number of remoting techniques (SOAP, REST, XML-RPC, etc.)
Services are the natural owners of units of work; they should manage connections and transactions.
I would create a service layer, rather than add database views.
The repository deals with data access only, the service layer has business logic, the controller is very slim and simply maps the information it is given to a model.
The service layer doesn't necessarily mean a WCF service or an ASMX service, it can be a business layer that you reference.
I have silverlight application, where I use Entity Framework(PostgreSQL) and WCF(not RIA).
Here is the problem:
in database I have table organization and table of contacts. Organization has set of contacts.
EF entity is not a data contract used by wcf. I use convertor to make datacontract from entity and vice versa. So my question is how to save related entities like hibernate saveupdate(cascade="save-update")?
Entity framework doesn't have cascade updates. You must manually handle changes = you must manually decide which contracts were modified, which were added and also wich were deleted. MS decided to solve this inconvinience by introducing Self tracking entities but they are not always bullet proof and are harder to use in Silverlight because STEs code must be shared among client and server.
In my database I have a User table with many related entities including Pets, Cars, Houses. More often than not my application will be working with just the User, however sometimes it will need to work with its related entities as well.
I'm planning to use Data Mappers (and Table Data Gateways) in Zend Framework. A few questions:
I think I'll have a BaseUser class, and an ExtendedUser class, with a Mapper for each. The ExtendedUser will inherit from the BaseUser, and the ExtendedUserMapper will inherit from the BaseUserMapper. Does this sound reasonable?
When my ExtendedUserMapper is working with related entities (such as a Pet, or a Car), it would call methods on a PetMapper, CarMapper, etc. Does this sound reasonable?
I am new to the Data Mapper pattern so am looking for a 'sanity check'.
Watch this presentation and you'll understand how to use services and data mappers.
I’m using NHibernate with RIA Services and Silverlight 4. I create DTOs for transferring the data via RIA Services rather than distributing my domain layer objects (as per Martin Fowler’s First Law of Distributed Object Design: “Don’t distribute your objects!”). The DTO objects are flattened down to two layers from five corresponding layers in the domain layer.
Here’s my problem. After making changes in Silverlight 4, RIA Services knows which DTO objects have been modified, but in the server-side update code I need to transfer the changes back to the “real” domain layer objects so that NHibernate can apply these changes back to the database. What’s the best way to do this?
Since the DTOs are intended to be lightweight, containing only the information that is needed on the client side, I obviously would not want to embed the corresponding domain objects inside the DTOs.
Here are a few of possibilities that I’ve considered:
1) Hold references to the domain objects within the DTO objects. As long as only the references get serialized and sent across the wire, not the entire referenced objects, then this might be a reasonable approach. Of course, the references wouldn’t be valid on the client side because they would point to non-existent memory locations, but at the end of the trip they could be used server side. (?)
2) Same as above but only save a reference to the domain aggregate root in the DTO object. Then use object relationship traversal to get to the other related domain objects.
3) Store the IDs of the domain objects in the DTOs and use NHibernate’s “Get” by ID or “Load” by ID functionality to retrieve the correct domain objects so that the updates can be applied.
4) Same as above but only use the “Get” or “Load” for the aggregate root and then use traversal for all related objects.
Perhaps none of the above is ideal and there is a better approach…
Whenever I build an access layer on top of ORM, I typically go ahead and put whatever the unique key is for the entity in the DTO, so that is tracked, and of course support for default(T) in the case of an add.
Then, when the object comes back to the server side, I can easily do a Load, marshall the changed values over from the DTO and then either let the session save it or perform an explicit save.
This would be your 3/4.
To answer your question at basic level - you may want to look into presentation model. Deepesh from RIA Services team has a good introductory blog post about it.
Also, you could use ID instead of reference (i.e. intrinsic, serializable value instead of app-domain-scoped object reference) and use [Association].
To answer at the next level, presentation model usage still involves work and additional types. It makes most sense when the shape of the model you want to see is substantially different from that on the server (whether a rich domain model or just DTO-based model). The increase in number of types and the need to map between them is the cost you pay for the flexibility. There are cheaper options that do less - e.g. non-public members, serialization directive [Exclude] etc that let you shape the code-gen'ed and serialized model. They may be worth considering. After all, the types on two sides of the trust boundary are very different by default (e.g. your types on the server vs code-gen'ed types on the client).
HTH
Dinesh