I have a database with a gazillion entities, I watched Tim Heuer's video about Silverlight & RIA Services, and he explained how to generate a DomainService.
My question is, should I use many domain services for each entity or merge them all along with all their queries into one big DomainService?
You would typically use a Domain Service for a domain of information (i.e. related entities).
That will usually be either:
all/most tables/entities, or
groups of closely related tables/entities, or
the odd single table/entity
With RIA services it is certainly easier to import them all at once into a single model and have RIA spit out one (very large) domain service file.
Make sure you try out the new RIA Services SP1 (now in Beta) as it now supports complex types and some other new stuff.
Related
I cannot fully understand in which case I will use DomainService and
in which case ApplicationService. Your documents are not detailed
enough on this subject. Can you give a more detailed explanation
with an example?
What could be a problem if I only use ApplicationService and never
use DomainService.
Which operations should I do in DomainService?
What kind of a way should I follow in order to distinguish these two
services from each other.
Short answer: Only use Domain Service if you need that additional level of abstraction.
Long answer as follows.
1. When do I use Domain Service?
From the documentation Domain Services #Introduction:
Creating a Domain Service is especially needed when;
You implement a core domain logic that depends on some services (like repositories or other external services).
The logic you need to implement is related to more than one aggregate/entity, so it doesn't properly fit in any of the aggregates.
Example from the documentation Domain Services #Introduction: When assigning an Issue to a User, check that the number of Issues assigned is not more than or equal to a certain number.
Example from the tutorial Part 6: Authors: Domain layer: When changing the Name of an Author, check that there is not already an author with the given name.
2. What could be a problem if I don't use Domain Service?
You could miss a check that is a core domain logic or business rule.
But generally, no problem. From the tutorial Part 6: Authors: Domain layer:
DDD tip: Do not introduce domain service methods unless they are really needed and perform some core business rules.
3. Which operations should I do in Domain Service?
See examples in #1 and #4.
4. How should I distinguish Domain Service from Application Service?
From the documentation Domain Services #Application Services vs Domain Services:
While both of Application Services and Domain Services implement the business rules, there are fundamental logical and formal differences;
Application Services implement the use cases of the application (user interactions in a typical web application), while Domain Services implement the core, use case independent domain logic.
Application Services get/return Data Transfer Objects, Domain Service methods typically get and return the domain objects (entities, value objects).
Domain services are typically used by the Application Services or other Domain Services, while Application Services are used by the Presentation Layer or Client Applications.
From the tutorial Part 8: Author: Application Layer:
Used the AuthorManager (domain service) to create a new author.
Used the IAuthorRepository.InsertAsync to insert the new author to the database.
Used the ObjectMapper to return an AuthorDto representing the newly created author.
DDD tip: Some developers may find useful to insert the new entity inside the _authorManager.CreateAsync. We think it is a better design to leave it to the application layer since it better knows when to insert it to the database (maybe it requires additional works on the entity before insert, which would require to an additional update if we perform the insert in the domain service). However, it is completely up to you.
#aaron'a answer is awesome. I just want to point to another document which discusses "Domain Services vs Application Services": https://docs.abp.io/en/abp/latest/Domain-Driven-Design-Implementation-Guide#domain-logic-application-logic
I suggest you to fully read this guide if you want to implement DDD with the ABP Framework. If you still find the documentation is not detailed enough, you can read Domain-Driven Design book of Eric Evans. DDD is not a concept created by the ABP Framework and there are tons of resources on the web and there are many books.
I have a small Silverlight app, using WCF RIA for getting and manipulating data. I was thinking what modifications I have to make to port the app to WP7 or other platforms.
The DomainContext proxy generated in the SL app is not supported in WP7 afaik. (Am I right on this?)
So I think my options are exposing OData or SOAP (or JSON) endpoints for the DomainService. A lot of sources say that OData is pretty limited, but what about the DataServiceContext class? Is this almost as functional as the DomainContext? I mean it tracks my downloaded entities, and when I save the changes, it saves the tracked modifications to the server, and this is very useful I think.
But what about the SOAP endpoint, or platforms which don't have so many features like the WP7 DataServiceContext? How can I make modifications in this case? Do i have to track every change manually, and for example if I want to insert 45 entities, I have to insert them one-by-one with a basic insert (CRUD) method? (The generated service proxies are doing the same in the background btw?)
So to sum up my questions, which approach is the best, and the most platform independent? I think SOAP is the choice, but since I never developed on Android or iOS, i'm not sure. And also I'm not sure if I can send back IQueryable in every endpoint (or there is an equivalent on every platform?). If I can't, do i have to modify all my custom queries in the wcf ria domain service, to suite the limitations of SOAP?
I am thinking about replacing the business layer with BizTalk orchestrations exposed as WCF services as a standard architecture for many of our apps. Essentially ASP.NET and WinForms apps will call these services to retrieve and update data in many of our LOB databases among other things. Some of the services will also be exposed to partners.
As for the data access, I can certainly use the SQL Adapter, but I think it's not the cleanest way to do it, and the fact that it's tightly coupled to SQL Server also makes it a bad idea for me. I would like to use Entity Framework based custom DAL's or perhaps generated from tools like SubSonic, etc.
Is this a good idea? From my Google searches, I can't find many people doing this kind of thing or any comments on how it might have worked out for them.
What's your take on this? Any ideas on where to cache data, concurrency issues, etc.?
You will probably have an easier time using straight WCF and something like NHibernate or EF. These services consuming and returning DTO's and not raw entities. If you do have heavy business logic or mapping that needs done, BizTalk can sit in front or with ESB even expose mapping services to your data service on the side.
Also check out the new WebApi stuff. http://wcf.codeplex.com/
And BizTalk is not great at doing low latency ... you will get some overhead on all the service calls.
If you have to do a lot of service aggregation there MIGHT be a case for doing it this way ... but beware the latency and overhead you get from an integration platform that is aimed at giving you all kind of services around messaging integrity etc.
My team is considering using an up to date version of Entity Framework with a WinForm or WPF application which will be downloaded by users and installed on their machines.
This will connnect through WCF to our database, and the app will use LINQ queries through EF to interact with the database.
Is this secure? Can the application be reverse engineered, and a competitor see our database structure and business rules?
Is this architecture acceptable? Or if the risk is high, should the structure be abstracted behind an interface?
I imagine it depends a bit on how your WCF service is going to work. Webservice or Windows Service? Encryption? If you are not encrypting and you are serializing your returned objects in XML, it is possible someone could snoop that XML stream, and get an understanding of the structure of the entity (Pretty sure mapping information or Storage Layer information is not included in the serialized entity).
As far as Entity Framework goes, assuming an attacker cannot get to the edmx or the resulting EDM constituent files, and they can't get access to the database directly, you should be good. Entity Framework EDMs compile pretty similarly to other assemblies. So long as you secure the transport from service to client, you should be good.
I am doing something I consider to be pretty normal (although I personally haven't had to do it before), and I have assumed there'd be a 'no-brainer' way forward, but Im yet to find it - which is really frustrating.
I will be creating a WPF application, which is a data-oriented business application. My data will come from a remote IIS server (that I control) that has a standard SQL server 2008 database, so Web services/WCF seem to be the way forward. The remote service needs to be secure (reasonably) via a user (of the WPF client) username/password login.
I dont want to use 3rd party ORM products, but I expect the data layer (between the service and the database) to be able to cope with very simple ORM type functionality (I really dont want to hand-craft a data retrieval and persistence layer). Im not worried about concurrency very much as this will be a fairly simple app.
My options seem to be one of the following:
ADO.NET Entity Framework over WCF
Linq2Sql over WCF
WCF Data Services
On further investigation, none of the above seem to be the 'no brainer' Im after
1) ADO.NET entity Framework - Ive had a play with this and getting all sorts of issues serializing objects over WCF. Even when I try to generate POCO entities and use them, Im having to decorate service contracts with custom attributes just to get it to not error all the time, and I seem to have to hand-crank anything more than a flat object graph. It seems to me that EF simply isn't designed to be exposed via a service.
2) Linq2Sql - This doesn't seem much better than EF. I seem to have to hand-crank too much stuff. Ive tried the designer and SQLMetal but nothing seems to 'just work' - it all needs fiddling with.
3) WCF Data Services - this seems like a good option on the face of it, but essentially it seems like I'm just exposing my SQL database tables 'in the raw' over the service layer. Im not an expert in this technology by any means but it seems like a potentially dangerous approach, and on top of that it doesnt seem to support any kind of access security as standard (you have to hack it to require authentication it seems).
As I said, this scenario feels like it should have a no-brainer solution, but Im still scratching my head. Ive done lots of things with .NET technologies, but to be honest this area represents a bit of a hole in my understanding, so I apologize if any of my comments or assumptions are naive.
Of course, it may well be that the 'hacky' long-way-round on EF or Linq2SQL may be all I can do, in which case I can roll up my sleeves, and accept the fact that I haven't missed a more elegant solution.
Any help/advice will be much appreciated.
This is a tad subjective, but i'll offer my opinion.
First of all, forget L2SQL - it's basically obsolete and doesn't have the full POCO support of EF4 (it can be done, but needs XML tinkering, or SQLMetal generation), which means serializaing your entities will be a left-to-right entity cloning nightmare.
I would go with ADO.NET Entity Framework over WCF, Entity Framework 4.0 specifically. You will have a wealth of flexibility in your model (including the ability to apply OO principles such as inheritance).
Use Self-Tracking-Entities. Yes, you have to decorate service contracts - this is by design, and there are many reasons for this.
You could always use DTO's, as opposed to serializing the actual EF entities.
OData is really good as well in it's flexibility and simplicity. But if your only consuming your model via a single client application, a specialized service layer (WCF) is a better approach IMO.
3) WCF Data Services - this seems like
a good option on the face of it, but
essentially it seems like I'm just
exposing my SQL database tables 'in
the raw' over the service layer.
That might be a first impression - but it's fundamentally wrong. What you're exposing over the web is a model - and you have full control over what gets into that model, and how consumers of your WCF Data Services might be able to see and/or even update entities in that model.
That's where Entity Framework comes in and shines (and where Linq-to-SQL miserably fails): you can grab your database (or at least parts of it) into an Entity Data Model, and then modify it. You can tweak your entity names to be totally different from your table names, you can add computed attributes, you can remove certain attributes and much more.
If you're talking about a fairly simple app, that's definitely the way I'd go:
grab your database and turn it into an Entity Data Model using EF
expose that EDM over WCF Data Services and define what can be seen read-only, and what might even be updated over the wire