服务层方法参数设计疑问：使用DTO与直接传入单个参数的优缺点对比

Great question—this is a super common dilemma when building backend services, especially in TypeScript/Node.js setups. Let’s break down both approaches with their clear pros and cons, so you can decide based on your specific use case.

Approach 1: Using a DTO (CreateSomeDto) #

export class SomeService{
  async create(dto: CreateSomeDto) {}
}

Pros #

• Strong Typing & Readability: A DTO bundles related parameters into a single, named type. Anyone looking at the method signature immediately knows exactly what data is required (no more counting or guessing at random string/number arguments). It’s self-documenting—CreateSomeDto tells you this is the data structure for creating a "some" resource.
• Easy Scalability: If you later need to add new fields (like authorId or publishDate), you only modify the DTO class. No need to rewrite the service method’s parameter list, and all callers (like controllers) just update their use of the DTO instead of adjusting argument counts/orders.
• Centralized Validation: DTOs work seamlessly with validation libraries (like class-validator in NestJS). You can define validation rules directly on the DTO, so invalid data gets caught before it even reaches the service layer. This keeps your service logic focused on business rules, not input checking.
• Cleaner Abstraction: When done right (storing DTOs in a shared module, not tied to controllers), it creates a clear contract between layers. Controllers map request data to the DTO, services consume the DTO—no messy cross-layer dependencies.

Cons #

• Potential Dependency Risks: As you noted, if DTOs are defined in the controller layer, the service layer ends up depending on the controller, breaking the "controller depends on service only" principle. But this is avoidable: just put DTOs in a shared dtos or contracts module that both layers import.
• Minor Boilerplate: For tiny, simple methods (1-2 parameters), defining a whole DTO can feel like extra work.

Approach 2: Using Individual Arguments #

export class SomeService{
  async create(title: string, content: string) {}
}

Pros #

• Strict Unidirectional Dependency: The service layer is completely independent—no need to import any DTOs or controller-specific types. Controllers just extract request data and pass it as raw values, so the service never depends on anything outside itself.
• Quick & Simple: For trivial use cases (like a method that only needs two basic parameters), it’s faster to write without the extra DTO setup.

Cons #

• Poor Scalability: Add one more parameter, and you have to update the service method signature and every single place that calls it. This gets messy fast as your business logic grows.
• Readability Issues: With more than 2-3 parameters, the method signature becomes cluttered (e.g., create(title: string, content: string, authorId: number, isPublished: boolean)). Even worse, mixing same-type arguments makes it easy to accidentally swap values (passing content where title should go) without TypeScript catching it.
• Scattered Validation: You either have to validate each parameter in the service layer (cluttering business logic) or handle validation in the controller (spreading logic across layers). No single source of truth for what valid input looks like.
• No Semantic Context: A list of raw strings/numbers doesn’t tell you anything about the business purpose. Someone reading the method has to dig into the implementation to understand what those parameters are for.

When to Choose Which? #

• Go with DTOs for most business-focused services. They’re better for maintainability, scalability, and keeping your codebase clean—just make sure to structure your DTOs as shared contracts, not controller-specific types.
• Use individual arguments only for extremely simple, utility-style methods where you’re 100% sure the parameter list will never change (e.g., a helper method that concatenates two strings).

内容的提问来源于stack exchange，提问作者aryang