locked
Services. Please, need advice. Thank You. RRS feed

  • Question

  • Hello,

    I am creating a few services on a application:
    - MailService with SendContact and SendNewsletter methods.
    - TwiiterService with GetTweets and CreateTweet.

    When creating services is it "normal" to use static class and methods so I can use for example:

    TwiiterService.CreateTweet(Tweet tweet)

    Or should I not use static classes and have something like:
    TwiiterService service = new TwiiterService();
    service.CreateTweet(Tweet tweet);

    And should I use a model for this service like Tweet or just use something like:

    CreateTweet(String content, DateTime createdAt);

    I have the following structure:

    Infrastructure
    Domain > All repositories and entities from Entity Framework
    Application
    Presentation

    I am placing this services that connect to outside API's or Mail in Application. Is this ok?
    If I create an entity named Tweet to be used by TwiiterService where should I place it? In Domain.Entities?

    I am just trying to understand how to include and develop services on my application.

    Thank You,
    Miguel
    Wednesday, August 5, 2009 5:55 PM

Answers

  • In DDD services are stateless. Yes, using static methods is good design. My only gripe with static methods, which is why I mostly use instance methods, is testability. Static methods cannot be mocked or stubbed.

    Another thing you’ll have to watch out for in a domain model design is that static methods have procedural code. Over applying static methods often results in an anemic domain model.


    http://www.paulgielens.com
    Thursday, August 6, 2009 7:24 AM
  • Prefer entity types over primitive types. I'd go for Create(Tweet tweet). The application layer has a dependency on lower layers including the domain layer, so it should be no problem to consume entity objects in the application layer. For a picture of this layer approach see http://farm4.static.flickr.com/3589/3768488783_a8e80ed1fa_o.jpg


    http://www.paulgielens.com
    Thursday, August 6, 2009 1:24 PM

All replies

  • In DDD services are stateless. Yes, using static methods is good design. My only gripe with static methods, which is why I mostly use instance methods, is testability. Static methods cannot be mocked or stubbed.

    Another thing you’ll have to watch out for in a domain model design is that static methods have procedural code. Over applying static methods often results in an anemic domain model.


    http://www.paulgielens.com
    Thursday, August 6, 2009 7:24 AM
  • Maybe I will go for non static ... So I can test it.

    And would you use twitterService.Create(String content, String account, DateTime updated)?

    Or would you just do twitterService.Create(Tweet tweet)

    Where Tweet would be an Entity containing 3 properties: Content, Account, Updated

    Where should I add this Tweet entity?

    In Application layer together with TwitterService or in Domain.Model together with EF Entities?

    Sorry for so many question. I am trying to define this right so I always use the same approach in all my projects.

    Thank You,
    Miguel
    Thursday, August 6, 2009 12:04 PM
  • Prefer entity types over primitive types. I'd go for Create(Tweet tweet). The application layer has a dependency on lower layers including the domain layer, so it should be no problem to consume entity objects in the application layer. For a picture of this layer approach see http://farm4.static.flickr.com/3589/3768488783_a8e80ed1fa_o.jpg


    http://www.paulgielens.com
    Thursday, August 6, 2009 1:24 PM
  • The application layer has a dependency on lower layers including the domain layer, so it should be no problem to consume entity objects in the application layer. For a picture of this layer approach see http://farm4.static.flickr.com/3589/3768488783_a8e80ed1fa_o.jpg


    Yes, I know application layer can access lower layers.

    I wasn't just sure that since Tweet is not related with the database that I could place in Entities to.

    Usual I see Entities as objects mapped from a SQL database directly or using Entity Framework for example.
    Thursday, August 6, 2009 1:48 PM